On Monday, 22 April 2013 at 17:01:43 UTC, Diggory wrote:
I like this except for the proposed "addressOf" function from
DIP25 which is massively overkill. The safe-ness of & on a ref
should be determined by the compiler, so that initially it
could be unsafe but that could be relaxed when the compiler can
determine that the pointer does not escape. Syntactic
ambiguities with properties can be resolve several other ways
that are simpler and clearer.
Anyway the main point I had was that everyone seems to be
assuming that returning R-value references from a function is
bad. (The ONLY effect "scope ref" has in DIP36, above and
beyond "ref", is preventing the parameter being returned)
The fact is with DIP35 alone there is no way returning R-value
references can cause unsafe-ness:
int getRValue() { return 1; }
ref int forward(ref int p) { return p; }
void other(ref int p) { /* does something interesting with p */
}
other(forward(getRValue())) // Safe because other can't leak
reference
int* ptr = &(forward(getRValue())) // Would fail at compile
time because "forward" is marked "ref" rather than "out" so
compiler can tell that return value could be an R value
reference.
forward(getRValue()) = 1 // Compiler would at least produce a
warning because it can see that this code is assigning to
something that could be an R-value reference. This is not
unsafe just not useful.
So basically if this is implemented as suggested there is no
need for special treatment of R-values, which is good!
'scope ref' would allow, that both, lvalues AND rvalues can be
bound to. DIP 35 don't say anything about that.
Just to be clear:
The primary reason at all DIP 36 was created, was in general to
find a possibility that accept rvalues AND lvalues. That was
the initial reason.
