DIP69 - Implement scope for escape proof references
via Digitalmars-d
digitalmars-d at puremagic.com
Sun Dec 7 03:49:09 PST 2014
On Sunday, 7 December 2014 at 06:52:38 UTC, Sebastiaan Koppe
wrote:
> How would it break anything though? Wouldn't functions eligible
> for `consume` already have the programmer ensuring the
> arguments haven't escaped before/after the function call? In
> case they did a bad job - sure it would break - but it would
> have been a bug.
I don't think the breakage is a serious problem in this case, so
I obviously agree with you…
But, the deep-rooted problem is that you actually need different
properties associated with pointers to do this properly: unique,
single-threaded shared, multi-threaded shared, gc, non-owning…
And this could be resolved with templates and having the compiler
recognize pointer resolutions that lead to the same lower level
code (to avoid bloat). But the D authors don't want ownership
related pointertypes… and I can't see that work.
> I am a big proponent of dataflow analyses, but I got the
> feeling people think is it pretty hard. Couldn't find much
> detailed papers on it, so I don't know.
You can do it in a simpler and conservative fashion and accept
false positives (or negatives) so that you here-and-there have to
inject annotations like this: "trust me I have proven that this
property holds here", then let the compiler infer the rest.
With a good IDE this should be no biggie: just inject suggestions
in the code and let the programmer confirm/refine them.
If you want to guarantee memory-safety you should do it with a
single uniform mechanism, trying to do it bit-by-bit special
casing is not a good idea. So given the current approach, I'm
inclined to turn off @safe, make everything @nogc, write my own
libraries with unique_ptr/shared_ptr and call it a day… The
current approach does not address situations where I run into
memory related bugs in my own code.
More information about the Digitalmars-d
mailing list