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.
