On Thu, 09 May 2013 13:45:16 -0400, Peter Alexander
<peter.alexander...@gmail.com> wrote:
On Thursday, 9 May 2013 at 17:27:41 UTC, Steven Schveighoffer wrote:
Short answer: no matter what, we have to find a way to be able to write
one function that takes by ref, and accepts both rvalues and lvalues.
If ref const is that way, so be it. If auto ref is that way, so be
it. If it's plain-old ref, I'm fine with that too.
Allowing plain-old ref to bind to rvalues would be a massive mistake in
my opinion. See case (2) in the original post.
The case for it is operator overloads. Note that all operator overloads
are defined WITHIN types, and all operator overloads take 'this' by
reference. Without the hack currently in the compiler that 'this' is
allowed to bind by ref to rvalues, D would be near useless.
Consider that today, this doesn't work for custom structs, unless you
allocate the result on the heap.
((a + b) + (c + d))
The original case 2 looks bad, but not very common. With by-ref turning
into by-value, you are in effect changing the API and functionality. It
would just mean that you wouldn't make that change, or change the type
name at the same time (so it wouldn't just compile on existing code). I
think someone later mentioned that if 'fix' was a method, it would break
even today (with ref-binds-to-this hack).
You should also consider that even if we break existing code by changing
by-ref into by-value, there's no guarantee the person maintaining the code
does the right thing.
It seems that 'auto ref' would be suitable, provided we can find a way
for it to work with normal functions (in a sensible way, not like
templates).
I think first we have to prove that auto ref is worth the extra cognitive
load. Every overload style we add has a large multiplicative effect on
boilerplate.
As I said before, I'd be ok with any solution, as long as we can bind
rvalues to some form of ref.
-Steve
