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).

>> 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.