Escaped scoped

[Steven Schveighoffer]

On Mon, 04 Jan 2010 14:33:24 -0500, Don <nospam at nospam.com> wrote:

> Steven Schveighoffer wrote:
>> On Mon, 04 Jan 2010 05:52:19 -0500, bearophile  
>> <bearophileHUGS at lycos.com> wrote:
>>
>>> If I compile the following code with DMD with and without the scope  
>>> annotation I can see that both versions compile and the version with  
>>> scope deletes the object. Is the compiler acting correctly here? I'd  
>>> like the compiler to refuse to compile this code when the scope  
>>> attribute is present (this is a reduced example from a bug I've just  
>>> removed from a program of mine):
>>>
>>> class Foo {}
>>> class Bar {
>>>     Foo x;
>>>     void spam() {
>>>         scope Foo temp = new Foo();
>>>         this.x = temp;
>>>     }
>>> }
>>> void main() {}
>>  Scope is not a type constructor, so once the compiler passes the line
>>  scope Foo temp = new Foo();
>>  the compiler sees temp as type Foo, not scope Foo.  So it is ignorant  
>> on the next line to know to stop you from doing something foolish.
>
> I don't think that's true, actually. The compiler has a SCOPE storage  
> class internally. Not sure what it's used for, though.

Not sure of the internals, but from what I understand, a storage class is  
just a clue on how to store it, it does not affect the type.  For instance  
temp can legally be assigned to a different instance that isn't stack  
allocated, or another variable that isn't scope can be assigned temp.  At  
that point, any possibility for scope protection is lost.  And without  
some significant analysis, the compiler is lost after the declaration.

>
>> When using scope, it is on you to ensure that it doesn't escape.
>
> Yes, I suspect it's impossible for the compiler to do perfect escape  
> analysis. But it probably wouldn't be difficult for it to do some.

You need some sort of analysis to prove that the scope variable isn't  
reassigned to another instance.  The reason it works in the way it does  
for passing non-closure delegates to functions is because the function  
call and delegate creation are all in one statement, so the compiler has  
all the info available to make the right decision.  Just one extra  
statement causes a closure allocation:

int x = 5;
void fn()
{
   x = 6;
}

auto dg = &fn; // allocates closure
foo(dg); // foo accepts a scope delegate.

foo(&dg); // no closure allocation.

>
>> I think the compiler cheats a little bit on delegates, but it has  
>> severe limitations that I think make using delegates without  
>> accidentally allocating closures difficult.
>
> It could probably catch simple cases like this one, though.

I don't think without some major analysis, or some sort of type marking.

-Steve