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