DIP35: supplement to DIP25: Sealed References
Diggory
diggsey at googlemail.com
Mon Apr 22 10:01:42 PDT 2013
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!
More information about the Digitalmars-d
mailing list