DIP 36: Rvalue References

[Zach the Mystic]

On Wednesday, 10 April 2013 at 07:43:57 UTC, Dicebot wrote:
> Consistent behavior is important but it does not change the 
> fact that there two types of rvalues in the language - raw 
> literals (42, A.init) and constructed temporaries (A()). 
> Accepting rvalues of the first type in as mutable references 
> may be consistent from the point of view of syntax by 
> _extremely_ confusing semantics-wise:
>
> void foo(scope ref int x)
> {
>     x = 32;
> }
>
> void main()
> {
>     foo(42); // erm, 32 is the new 42 or ref is not actually 
> ref?
> }
>
> Beauty of "in ref" is that in that case user can't use it in 
> any way that may disclose the fact the temporary variable for 
> non-adressable entities is created. For mutable scope ref it is 
> not the case and we must leak implementation details, which is 
> never good.
>
> Another concern is that if someone tries to pass "42" as a 
> mutable ref, most likely he does not really wants it to be 
> mutable and "in ref" is a better match.
>
> This may not be consistent from the point of view of generic 
> code, but it is now consistent from the point of view of 
> programmer : A(...) construct always create temporaries, raw 
> value literals never do (well, they will for "in ref" but you 
> can't observe it). I think this is much more important.
>
> One extra thing to note is that test32 may actually work if it 
> instantiates T as "const int" for 42 (making it "in ref" 
> essentially), but I don't know if D rules allow it.

I think this is another case of two different features which may 
or may not be paired up together. If it is always okay to have A 
accompany B, and B accompany A, it's good from a syntax point of 
view because you only need one syntax for both of them. But if 
you pair them up and later think, I wish I could do A without 
having to do B, or B without having to do A, then you'll regret 
pairing them up because you'll either have to break code or live 
with what you've got.

When you say we shouldn't be able to return an rvalue 
temporaries, even if they're safe, I think it's reasonable, not a 
life or death issue. But if 'scope ref' is used to mean that, 
you're also saying that any *other* feature which wants 'scope', 
such as 'ref' safety (why I created DIP35, to highlight this), 
will automatically also have to take rvalue temps because they're 
bound up with it, it's more risky.

Some of these will be a judgment call - A and B  are sometimes so 
similar that it's better to save on syntax than differentiate 
them. 'const scope' might be the same way.