Scope storage class

[Steven Schveighoffer]

"Sergey Gromov" wrote
> Mon, 1 Dec 2008 14:10:27 -0500, Steven Schveighoffer wrote:
>
>> "Walter Bright" wrote
>>> Steven Schveighoffer wrote:
>>>> "Walter Bright" wrote
>>>>> Jarrett Billingsley wrote:
>>>>>> So my suspicion is correct, then?  That is:
>>>>>>
>>>>>> scope int delegate() b;
>>>>>> b = { ... };
>>>>>>
>>>>>> Will allocate on the heap?
>>>>> Yes. The scope for delegates takes effect as a parameter storage 
>>>>> class,
>>>>> not a local variable storage class. The reason is because it is the
>>>>> called function that decides what it's going to do with the delegate.
>>>>
>>>> Why?  It would be useful to allow local scope delegates.
>>>>
>>>> The compiler can just forbid passing the delegate to a function which
>>>> does not declare its parameter as scope.  I assume the compiler knows a
>>>> variable is scope since it must prevent escape of the delegate, no?  So
>>>> just use that information.  I thought that was the point of all this...
>>>
>>> In order to make that work, the compiler would have to do full escape
>>> analysis, which is a lot of work to implement.
>>
>> Maybe I've misunderstood the point of declaring a delegate parameter 
>> scope.
>>
>> Take the following example:
>>
>> void delegate(int) global_dg;
>>
>> void foo(void delegate(int) dg)
>> {
>>    global_dg = dg;
>> }
>>
>> void foo2(scope void delegate(int) dg)
>> {
>>    dg(5);
>> }
>>
>> void bar(scope void delegate(int) dg)
>> {
>>    foo(dg); // should this compile?
>>    foo2(dg); // should this compile?
>> }
>>
>> void baz()
>> {
>>    int y;
>>    void dg(int x) { y += x; }
>>    bar(&dg);
>> }
>>
>> Should bar's call to foo compile?
>
> It compiles.

I meant, should it compile in the final incarnation of this feature.

>> If it does, then the benefit of having
>> scope delegates is just a hint to the compiler that "I know what I'm 
>> doing".
>
> Yes, seems like for now it's just a hint.  No checking is done.
>
> The problem is, the declaration:
>
>  scope var = ...;
>
> means something completely different from
>
>  void foo(scope void delegate() dg);
>  foo(...);
>
> The former defines a scoped instance of a class.  Ideally it should fail
> if used with any non-class type because it makes no sense with
> non-classes.

I was proposing to MAKE scope var = &dg mean what I said it should mean.  I 
am not talking about the current spec.

> The latter defines a delegate in a non-escaping context.  Currently such
> definition is possible only as a parameter to a function call.

Currently being the key word here ;)

> If delegate is defined in a non-escaping context, it gets a stack
> closure.  If it is defined as a scoped instance of a class... well, it
> makes no sense, so the scope is ignored and the delegate is created as
> usual, with a heap-allocated closure.

It makes sense.  A scope variable doesn't escape it's scope.  Why should 
this be limited to classes?  In fact, the scope delegate versus non-scope 
delegate is 100% analogous to scope classes versus non-scope classes.

My point in all this is Walter is saying it cannot be done, when in fact it 
can, and should be easy to determine, assuming that the eventual goal of 
this feature is to prevent scope delegate escapes.  Without knowing which 
delegates are scope and which are not is very important to escape analysis. 
Even partial escape analysis.  If the compiler can't determine that, then 
all this does is give a hint to the compiler, which isn't very useful at 
all, and seems half-ass in the face of all the other great features D2 is 
creating.

-Steve