DIP35: supplement to DIP25: Sealed References

[Namespace]

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.