auto ref - again

[Era Scarecrow]

On Sunday, 27 January 2013 at 04:38:44 UTC, deadalnix wrote:
> On Sunday, 27 January 2013 at 02:28:26 UTC, Era Scarecrow wrote:
>> Having ref accept rValues seems like a bad idea. If the source 
>> is const/immutable then it might be allowed, but more likely 
>> temporaries will be made for convertion from rValues to 
>> lValues, then passing off the temporaries. The temporaries to 
>> work right likely need to be at the top-most scope of whatever 
>> function you happen to be in; Beyond that I'm not sure how 
>> else the auto ref could be implemented safely.
>
> I have yet to see an instance of such problem in real life, but 
> quite frankly, I tired to argue.

  I would have thought it was obvious. I have done before where 
all my work was done from a ref. Now being that i wouldn't want 
to duplicate my code twice, the non-ref simply forwards to the 
ref. auto ref may automate removing the need to explicitly 
forward temporaries or make them yourself; Kinda like how scope 
makes things easier.

  For some reason opCmp is coming to mind as a good example.

   struct S {
     //90%+ of the time this will be called,
     //so without needing to do overhead we will do our compare.
     int opCmp(ref S rhs);

     //why duplicate code? Just forward to ref
     int opCmp(S rhs) {
       return this.opCmp(rhs);
     }
   }

   S l, r;
   assert(l >= r);   //uses ref
   assert(l >= S()); //uses non-ref, forwards to ref

  I remember I came up with a good reason why the temporary should 
be added to the outer scope, but the reason escapes me right now.

  But as I'm thinking about the other half having ref accept 
rValues, I would see that acceptable if the following qualified.

  1) Must be 'const ref' or 'immutable ref', no changes means 
likely no special handling.
  2) No special postblit or opAssign operations
     and/or
  3) The rValue in question is a POD (Plain Old Data)

  Since likely the rValue would have to be statically known at 
compile-time so it could create a read-only instance in the data 
portion, then refer to it. By itself it seems fairly simple to 
add in; but I'm honestly not sure, not being able to tell them 
apart when you need to seems like an annoyance, likely that C++'s 
been dealing with.