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
}
