Tango vs Phobos

[Koroskin Denis]

On Mon, 11 Aug 2008 22:39:56 +0400, Sean Kelly <sean at invisibleduck.org>  
wrote:

> Frank Benoit wrote:
>> Jarrett Billingsley schrieb:
>>> "Lars Ivar Igesund" <larsivar at igesund.net> wrote in message  
>>> news:g7mboq$qcl$1 at digitalmars.com...
>>>
>>>> Also as long as closures are allocated on stack, that is likely to be  
>>>> rather
>>>> detrimental to the performance.
>>>
>>> Heap.
>>>
>>> That is another major blocker for me besides const.  Most of my code  
>>> uses nested functions that are never supposed to be closures, and this  
>>> "feature" would cause it all to unnecessarily allocate memory.
>>>
>>  i second that.
>> It is an closure solution which was implemented too easy, imho.
>>  1.) it breaks the semantic of an existing syntax. So existing code can  
>> be broken without any warning. (change in runtime behaviour)
>
> Yup.  Much like the change in meaning of "const," which I've admittedly  
> complained about perhaps overmuch.
>
>> 2.) there is still no alternative syntax to get the old behaviour
>
> I would prefer that the old behavior the the default and that "new &fn"  
> or something similar would be used for full closures.
>

If I understand the issue correctly, it's not a delegate itself that  
should be allocated on heap but rather a function context (i.e. local  
variables):

auto foo()
{
     int i = 0;

     int bar() {
         return ++i;
     }

     return &bar;
}

It's clear enough that i should be allocated on heap.

On the other side, there is a scope modifier, that doesn't allow returning  
of pointer to the attributed variable:

auto foo()
{
    scope Bar bar = new Bar();
    return bar;                  // illegal
}

So these variables should be allocated on stack in any case, even for  
delegates:

auto foo()
{
    scope Bar bar = new Bar();

    Bar foobar() {
       return bar;
    }

    doSomething(&foobar);	// legal (unless foobar is saved somewhere in  
global scope)
    return &foobar;              // illegal
}

Note that bar is a scoped variable and isn't supposed to be heap allocated.

So a solution would be to allow marking built-in type and struct instances  
as scope, too, and those variable won't be heap allocated.
The default one, however, would be non-scope, i.e. heap-allocated.

It fits perfectly with current semantics, it allows marking of some  
variables as heap- others as scope-allocated (flexibility), it doesn't  
introduce any new keywords or concepts.

>> 3.) the closures are not really closures. E.g. const variables can  
>> change value. (Bug 2043)
>
> This one, at least, is clearly a bug.
>
>
> Sean