www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - opAssign and const?

reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 5 May 2012 at 04:15:21 UTC, Jonathan M Davis wrote:
 On Saturday, May 05, 2012 05:50:26 Era Scarecrow wrote:
 On Saturday, 5 May 2012 at 03:32:06 UTC, Jonathan M Davis 
 wrote:
 ---------
 Func­tions are over­loaded based on how well the 
 ar­gu­ments to a func­tion can match up with the 
 pa­ra­me­ters. The func­tion with the  best match is 
 se­lected. The lev­els of match­ing are:
 
 1. no match
 2. match with im­plicit con­ver­sions
 3. match with con­ver­sion to const
 4. exact match
 ---------


Hmm maybe it should have a preference for Lvalue vs Rvalue... So... Walter or Andrei? 1. no match 2. match with im­plicit con­ver­sions (Lvalue required) 3. match with con­ver­sion to const (Lvalue required) 4. match with im­plicit con­ver­sions 5. match with con­ver­sion to const 6. exact match

This will likely be _very_ relevant to the proposed changes which make ref and const ref work with rvalues (the details on that are still being sorted out, I believe). However, I don't believe that either Walter or Andrei pays attention to D.Learn, so if you want to bring it up for discussion, post about it in the main newsgroup (not to mention, your post is buried enough in this thread that many who _do_ pay attention to D.Learn wouldn't see it).

This is a topic pulled from D.learn. http://forum.dlang.org/thread/qyzvvlirbcklwjealnaa forum.dlang.org Quick brief overview: While trying to use opAssign to copy data (and keep arrays separate), one opAssign is being selected over the other. The first is for a reference (ref X) which does a buffer[] = rhs.buffer[] copy, while (X) for the temporaries the array is passed over, as buffer = rhs.buffer When adding changing (ref X) to (ref const X), it is calling the (X) which breaks my array separation when (ref const X) should work fine. (Afterall I'm promising not to change the data, not requiring it to be const).
May 04 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
 On Saturday, May 05, 2012 05:50:26 Era Scarecrow wrote:
 Hmm maybe it should have a preference for Lvalue vs Rvalue... 
 So... Walter or Andrei?
 
  1. no match
  2. match with im­plicit con­ver­sions (Lvalue required)
  3. match with con­ver­sion to const (Lvalue required)
  4. match with im­plicit con­ver­sions
  5. match with con­ver­sion to const
  6. exact match



Thinking about this, perhaps it should attempt the following order instead. (Not sure of the no match here) 2. match with con­ver­sion to const (Lvalue required) 3. match with im­plicit con­ver­sions (Lvalue required) 4. match with con­ver­sion to const 5. match with im­plicit con­ver­sions 6. exact match 7. no match - Templates attempted 8. error? Trying the more restrictive ones first. You can convert mutable to const, but you can't turn it around without specific cast and knowledge. If you think about it too, very little code will likely be const, or ones that are const usually will be by themselves so ordering isn't going to be as important.
May 07 2012