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).
