Just want to mention again that Issue 7965 is a really nasty wrong-code bug that is difficult to find unless you know about it.

I face this Issue in almost every my D program with non-trivial std.algorithm usage and I suppose I'm not alone.

If there is no plans to fix it in near future this _must_ be mentioned in std.algorithm page and in other places in docs because it's really possible to avoid it every time you use std.algorithm.

It's not a joke! Such things must be mentioned in docs or D is unusable for non-experienced D developers.

http://d.puremagic.com/issues/show_bug.cgi?id=7965

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Saturday, 16 June 2012 at 20:16:52 UTC, Denis Shelomovskij wrote:
> Just want to mention again that Issue 7965 is a really nasty wrong-code bug that is difficult to find unless you know about it.
>
> I face this Issue in almost every my D program with non-trivial std.algorithm usage and I suppose I'm not alone.
>
> If there is no plans to fix it in near future this _must_ be mentioned in std.algorithm page and in other places in docs because it's really possible to avoid it every time you use std.algorithm.
>
> It's not a joke! Such things must be mentioned in docs or D is unusable for non-experienced D developers.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=7965

 Looks to me like a frame pointer bug for the delegate (Or lack of it?)...

 Based on the setup, it should also be illegal to pass the struct outside of the scope it's in due to the delegate in the struct (Unless the variable(s) in question are static).

On 06/16/2012 11:19 PM, Era Scarecrow wrote:
> On Saturday, 16 June 2012 at 20:16:52 UTC, Denis Shelomovskij wrote:
>> Just want to mention again that Issue 7965 is a really nasty
>> wrong-code bug that is difficult to find unless you know about it.
>>
>> I face this Issue in almost every my D program with non-trivial
>> std.algorithm usage and I suppose I'm not alone.
>>
>> If there is no plans to fix it in near future this _must_ be mentioned
>> in std.algorithm page and in other places in docs because it's really
>> possible to avoid it every time you use std.algorithm.
>>
>> It's not a joke! Such things must be mentioned in docs or D is
>> unusable for non-experienced D developers.
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=7965
>
> Looks to me like a frame pointer bug for the delegate (Or lack of it?)...
>
> Based on the setup, it should also be illegal to pass the struct outside
> of the scope it's in due to the delegate in the struct (Unless the
> variable(s) in question are static).

Passing the struct outside of the scope it is in must be legal and
create a heap frame if it references any of the stack variables.

What delegates are you talking about?

On Saturday, 16 June 2012 at 22:13:44 UTC, Timon Gehr wrote:
> On 06/16/2012 11:19 PM, Era Scarecrow wrote:
>> On Saturday, 16 June 2012 at 20:16:52 UTC, Denis Shelomovskij wrote:
>>> Just want to mention again that Issue 7965 is a really nasty wrong-code bug that is difficult to find unless you know about it.
>>>
>>> I face this Issue in almost every my D program with non-trivial std.algorithm usage and I suppose I'm not alone.
>>>
>>> If there is no plans to fix it in near future this _must_ be mentioned in std.algorithm Page and in other places in docs because it's really possible to avoid it every time you use std.algorithm.
>>>
>>> It's not a joke! Such things must be mentioned in docs or D is unusable for non-experienced D developers.
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=7965
>>
>> Looks to me like a frame pointer bug for the delegate (Or lack of it?)...
>>
>> Based on the setup, it should also be illegal to pass the struct outside of the scope it's in due to the delegate in the struct (Unless the variable(s) in question are static).
>
> Passing the struct outside of the scope it is in must be legal and create a heap frame if it references any of the stack variables.
>
> What delegates are you talking about?

 I had the impression that a function referencing the outer frame automatically was a delegate; Maybe I just messed up on the terms..

void func(){
int x;
 void y(){x++;};

//equal to??
 auto y = delegate void(){x++;};
}

On 06/17/2012 01:45 AM, Era Scarecrow wrote:
> On Saturday, 16 June 2012 at 22:13:44 UTC, Timon Gehr wrote:
>> On 06/16/2012 11:19 PM, Era Scarecrow wrote:
>>> On Saturday, 16 June 2012 at 20:16:52 UTC, Denis Shelomovskij wrote:
>>>> Just want to mention again that Issue 7965 is a really nasty
>>>> wrong-code bug that is difficult to find unless you know about it.
>>>>
>>>> I face this Issue in almost every my D program with non-trivial
>>>> std.algorithm usage and I suppose I'm not alone.
>>>>
>>>> If there is no plans to fix it in near future this _must_ be
>>>> mentioned in std.algorithm Page and in other places in docs because
>>>> it's really possible to avoid it every time you use std.algorithm.
>>>>
>>>> It's not a joke! Such things must be mentioned in docs or D is
>>>> unusable for non-experienced D developers.
>>>>
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=7965
>>>
>>> Looks to me like a frame pointer bug for the delegate (Or lack of
>>> it?)...
>>>
>>> Based on the setup, it should also be illegal to pass the struct
>>> outside of the scope it's in due to the delegate in the struct
>>> (Unless the variable(s) in question are static).
>>
>> Passing the struct outside of the scope it is in must be legal and
>> create a heap frame if it references any of the stack variables.
>>
>> What delegates are you talking about?
>
>   I had the impression that a function referencing the outer frame
> automatically was a delegate; Maybe I just messed up on the terms..
>
> void func(){
>   int x;
>   void y(){x++;};
>
> //equal to??
>   auto y = delegate void(){x++;};
> }

I see. What actually happens looks more like this:

struct StackContext{
    int x;
}
StackContext x;
static void y(StackContext* context){ context.x++; }

No delegate is created until the address of the nested function is
taken. If such a delegate is suspected to escape the frame, the
StackContext is allocated on the heap instead.