Overload resolution (value vs reference)

[Era Scarecrow]

On Monday, 22 October 2012 at 21:58:04 UTC, Jonathan M Davis 
wrote:
> AFAIK, there are no plans to change it. I don't think that it's 
> even been suggested.

  I thought I suggested it back for a different order of 
preferences. Basically boils down to accepting the const ones 
over the non-const whenever applicable and possible. Quite 
annoying that it was accepting non-const copy over const ref for 
the purposes I was going for.

> For the most part though, you can just have the non-ref version 
> call the ref version as long as there's a ref version with the 
> same constness, so even if you have to duplicate the function, 
> you don't have to duplicate its body. You might be stuck with 
> some duplication between the const and non-const overloads 
> though if you have all 4 of them.

  Yeah I know... I guess best practice is to offer all const or 
non-const of particular function names/uses, but that doesn't 
always want to work. Let's see how did that go...

  struct S {
    ref S opAssign(S s);           //move. TDPL pg. 257-259
    ref S opAssign(const ref S s); //copy (almost postblitz)

/* as of current, only the 'move' is always used unless the 
struct is actually const. inout isn't applicable I think. I'm 
promising not to change the input on the copy, and the move can't 
be const (if there's any addressing to transfer). I consider the 
reference the important distinction, yet the non-const is always 
called/preferred */

    ref S opAssign(const S s); //duplicate(s) of above in reverse
    ref S opAssign(ref S s);   //best match works better now
  }