On 8/31/13 2:57 PM, Brian Rogoff wrote:
> On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei Alexandrescu wrote:
>
>>> http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter
>>>
>>
>> That use will stay and is useful and uncontested.
>>
>> Andrei
>
> Sure, but my complaint is that that useful style is cramped by the
> inability to have scope on *local variables*.

Oh I see. Yes, if we do find a way to define scope to provide guarantees, that would be awesome.

Andrei

On 31.08.2013 22:33, Andrej Mitrovic wrote:
> On 8/31/13, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:
>> On 31.08.2013 21:52, Andrej Mitrovic wrote:
>>> On 8/31/13, Jacob Carlborg <doob@me.com> wrote:
>>>> T delegate (Args) dg = &result.__ctor;
>>>> dg(args);
>>>
>>> Ah, pretty cool workaround.
>>
>> Then, why not close that old bug?
>>
>
> It needs to be fixed first.

I thought you were discussing about and found a fix.

On 2013-09-01 01:09, Andrei Alexandrescu wrote:

> Oh I see. Yes, if we do find a way to define scope to provide
> guarantees, that would be awesome.

How about this:

Object bar ()
{
    scope a = new Object;
    return a;
}

void main ()
{
    bar();
}

In the above code the compiler can determine that it's unsafe to return "a", with the following error:

Error: escaping reference to scope local a

So apparently it can do some form of limited escape analysis. But it's quite easy to fool the compiler. The example below won't result in any compiler errors.

Object foo (Object o)
{
    return o;
}

Object bar ()
{
    scope a = new Object;
    return foo(a);
}

void main ()
{
    bar();
}

What if we can help the compiler a bit. If we want to pass a scope object to another function it's required that the function takes the parameter as "scope", like this:

Object foo (scope Object o)
{
    return o;
}

Object bar ()
{
    scope a = new Object;
    return foo(a);
}

void main ()
{
    bar();
}

Now the compiler knows the "o" in "foo" is scope allocated and will perform the same analysis it did in the first example. This time the error will appear in "foo" and not in "bar".

Perhaps we can allow returning scope allocated objects as well if the function is marked as such:

scope(Object) foo (scope Object o)
{
    return o;
}

Object bar ()
{
    scope a = new Object;
    return foo(a);
}

void main ()
{
    bar();
}

Now the error will appear again in "bar" since it doesn't return a scope object.

-- 
/Jacob Carlborg

On Sunday, 1 September 2013 at 09:24:46 UTC, Jacob Carlborg wrote:
> On 2013-09-01 01:09, Andrei Alexandrescu wrote:
>
>> Oh I see. Yes, if we do find a way to define scope to provide
>> guarantees, that would be awesome.
>
> How about this:
>
> ...

It is pretty much the meaning I have assumed when collaborating on `scope ref` DIP. Only problem here is, again (and again), attribute inference - using scope variables will require annotating most part of Phobos with `scope` function parameter attributes to be usable.

On Saturday, 31 August 2013 at 21:57:37 UTC, Brian Rogoff wrote:
> On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei
>> That use will stay and is useful and uncontested.

Actually, after a bit more experimentation, I don't object to removing the scope on local variable delegates. Replacing those with a nested function declaration and a local pointer to function seems to work fine with no GCing, at a very slight cost in elegance IMO; I prefer the delegates to using '&' on a function. It is good to see features being removed from D.

-- Brian