auto ref - again

[deadalnix]

On Sunday, 27 January 2013 at 12:58:17 UTC, Andrei Alexandrescu 
wrote:
> On 1/26/13 9:28 PM, 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.
>
> One simple matter that has been discussed here, which I've hit 
> only yesterday in a script was:
>
> string lines;
> ...
> auto r = regex(...);
> auto m = lines.match(r);
> // Get rid of the whole match
> m.captures.popFront();
> // This should be the first actual capture
> auto s = m.captures.front;
>
> The problem here is m.captures returns an rvalue. In turn that 
> rvalue is bound (arguably incorrectly) to the reference "this" 
> in the call to the member function popFront(). The method pops 
> the front off the temporary, leaving the original intact. The 
> subsequent invocation m.capture returns the value anew.
>
> This issue is a combination of properties that return rvalues 
> with the current (too liberal IMHO) binding of rvalues to 
> temporaries. The latter has been a design tidbit inherited from 
> C++, and it's been in D for a long time.
>

I think that it is unclear what should happen when a range is 
copied. This is an issue a ran into quite often.

It seems here that captures provide you a new copy every time. 
why not after all ? What is the problem here ?

BTW, unless you create a temporary storage, you can't call any 
method on a struct. This is why in the first place struct literal 
MUST have a storage (so it make sense to bind them to ref).