ref is unsafe

Jonathan M Davis jmdavisProg at gmx.com
Sun Dec 30 18:46:49 PST 2012


On Monday, December 31, 2012 03:34:18 Carl Sturtivant wrote:
> The implementation of delegates has solved an analogous problem.

Delegates use closures. The stack of the calling function is copied onto the 
heap so that it will continue to be valid for the delegate after the function 
returns. We don't want to be doing anything like that with ref, and it's 
generally, completely unnecessary. It's just that there are cases where you 
can escape such references if you're not careful, and the compiler currently 
considers those to be @safe, when they're not actually safe. So, we presumably 
need to do one of

1. Limit what can be legally done with ref to get rid of the problem.

2. Make ref @system in cases where we can't prove that it's @safe and try and 
prove it to be @safe in as many situations as possible.

3. Create a new attribute which has to be used when a function returns a ref 
to a parameter and use that to make it illegal to pass a ref to a local 
variable to such functions.

4. Something else that similarly protects against this at compile time without 
any extra overhead at runtime.

I really don't think that something like closures would be acceptable for ref 
parameters.

- Jonathan M Davis


More information about the Digitalmars-d mailing list