On Wednesday, 10 April 2013 at 02:41:10 UTC, kenji hara wrote:
I think having both 'ref' and 'scope ref' is still reasonable,
because:
1. According to DIP25, escaping ref parameter is always safe.
But, for
rvalue reference, it allows meaningless code.
// Even if this is allowed, it is safe. BUT will introduce bad
practice.
ref int foo(scope ref int x) { return x; }
// safe
ref int bar(ref int x) { return x; }
void test() {
int x;
foo(x) = 10; // may useful but...
foo(1) = 10; // completely useless!
bar(x) = 10; // may useful, and
bar(1) = 10; // disallowed.
}
'foo(1) = 10' is indeed completely useless, but I don't think all
uses are completely useless. But I will concede that allowing
things like 'foo(1)' may be useless *enough* to disallow it
without anyone feeling bad. I have made DIP35,
http://wiki.dlang.org/DIP35 , which utilizes 'scope' to actually
make DIP25 more flexible, which I think is probably good. The
example I used was the 'copy' function. 'foo' above, rewritten as
the copy function would be:
ref int foo(scope ref int x) {
int* y = new int;
*y = x;
return y;
}
DIP25 may *need* to use 'scope' in this way to know that foo()
will always give a fresh value - so it can treat it like a global
safely. Thus 'foo(1)' will return a fresh heap allocated copy of
"1".
ref int test() {
return foo(1); // allowed
return bar(1); // disallowed!
}
Without the 'scope' parameter, there would be no way the compiler
could know. Therefore, it is not completely useless.
2. Certainly 'scope' by itself _can_ imply 'ref'. BUT,
currently a function
parameter without 'ref' storage class implies having value
semantics (== copy).
This is slightly wrong, I suspect. 'out' parameters are
implicitly references.
If we change the 'scope' meaning to 'implicit ref', it will
break the
consistency.
And, 'scope' is already used for delegate parameter.
int opApply(scope int delegate(ref int) dg);
Such a semantic modification will silently change the meaning
of existing code. It's not good to me.
Generally, I agree. My argument is for a small convenience of not
having to type 'ref' when not necessary. It would mean that when
the type was implicitly a reference, such as a delegate or
object, 'ref' was *not* implied, whereas it *was* implied with a
value type. This may or may not wreak havoc on the generic type
system. I thought there might be an off-chance that it would
actually be a *convenience* for the type system, since it would
get the right level of referencing for the type involved.
I believe that the 'scope' keyword may be a necessary addition to
DIP25 to make 'ref' fully safe and flexible (DIP35). If so, then
there may be a conflict with using it only to mean rvalue
temporaries. They are two separate features. I believe that if
they are to be used together, it will be because it was decided
that whenever you want to stop a reference from escaping, you
*always* want to allow rvalue temporaries, and whenever you want
to allow rvalue temporaries, you *never* want them to be
returned. Right now, returning an rvalue temporary might seem
dangerous, but sealed references *are* part of the plan for D,
and there may be no need to see them as dangerous.
