• HOSOKAWA Kenchi (35/44) Aug 18 2009 This is a re-reply for "Re: escaping pointer to scope local array: bug o...

HOSOKAWA Kenchi <hskwk inter7.jp> writes:

This is a re-reply for "Re: escaping pointer to scope local array: bug or not?".
My former post is dropped in a hole of the news's tree topology :(

Steven Schveighoffer Wrote:
 remember, scope is a storage class, not a type modifier. "scopeness" is  
 only a hint to the compiler of where to store it originally, the hint is  
 not passed on to other variables which point to the same data.  I'm  
 surprised it's actually an error to try and return a scope variable.

 One way to get scope to work as you desire is to make it a type modifier  
 and define rules about assignment, but I'm not sure that's a good answer.  
 Another way is to perform escape analysis, but Walter has expressed that  
 he doesn't want to do that.  It would require an intermediate interface  
 language for imports where annotations could be added by the compiler.


It seems that scopeness as-is is not a "hint to the compiler of where to store
it originally" because 'scope' reference accepts object which is not allocated
out of scope.
This behavior is dangerous. Here is a example:

class C
{
        int i = 1;
        ~this() { writeln("~C"); }
        void foo() {}
}

const(int*) f(const C arg) {
        scope c = arg;
        return &(c.i);
}

void main()
{
        auto c = new C;
        auto p = f(c);    // destructor is called after f()
        writeln(*p);      // success, at first grance
        c.foo;            // runtime error: access violation
}

The instance have been collected at writeln(*p), hence escaped pointer probably
points a garbage.
The 'scope' is misleading rather than a hint in this case, since the resource
had been acquired far away from the 'scope'.
Additionally, the 'scope' destroys argument which have const storage class in
the scope.

Current behaviors of 'scope' are:
1. Prohibit returning the scope references (it is a storage class and not
transitive). (compile time)
2. Calling destructor for the referenced instance when the reference goes out
of scope. (runtime)

These behaviors do not represent RAII.
I suppose RAII has similarity to const/immutable, which is fully cared in D2:
* It is safe to reference values/objects from multi-thread, etc. if the
referenced object will not change.
* It is safe to destruct a object when a reference pointing it goes out of
scope, if the object is referenced only from the scope.


Consequently, the best answer is presumably make it a transitive type modifier.
At least adding rules about assignment, right-hand value of 'scope' reference
must be just allocated by new operator.
It is too dangerous for 'scope' reference to allow referencing object
originally allocated out of the scope, especially arguments of the function.