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