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