Newbie comments about D

[Oskar Linde]

Jarrett Billingsley wrote:

> "Kristian" <kjkilpi at gmail.com> wrote in message
> news:op.tefyzndb5xlco7 at mist...
> 
> (sorry, my newsreader is, for some reason, not quoting your message [and
> your message alone] properly..)
> 
> -----------BEGINQUOTE------------------------
> --- 5 ---
> 
> Hmm, could it be possible to automatically add auto/local attribute to
> objects that are not returned (by a function) and that are not assigned to
> anything? For example:
> 
> class File {...}  //the file is closed in the destructor
> 
> void f() {
>      File f = new File;  //auto File f = new File;
> 
>      f.open("myfile.txt");
>      f.doSomething();
> }
> 
> -----------ENDQUOTE------------------------
> 
> What if you did something like this:
> 
> void f()
> {
>     File f = new File("foo.txt");
>     aFunctionThatStoresTheFileHandleElsewhere(f);
> }
> 
> With the current semantics of RAII class references, this is perfectly
> legal, and would cause a terrible bug whereby 'f' would be destroyed at
> the end of the function and would no longer be a valid reference
> "elsewhere."
> 
> It's certainly a very interesting optimization idea, but it would require
> the compiler to know more than it possibly can, or it would require
> placing very stringent restrictions on how RAII (or these "implicit RAII")
> class references could be used.

This optimization is identical to the escaping delegate problem. With a
global escape analysis, the compiler could make a conservative statement
finding cases where f was guaranteed not to be stored anywhere. This would
also mean that all called class methods need to be analyzed, as one of them
also could save away the this-pointer at some place.

In the example above, either the File constructor, f.open or f.doSomething
could store the reference somewhere.

/Oskar