Feature Request: Change the delegate type to void[] data insteadofvoid *ptr.

[downs]

BCS wrote:
> Reply to Downs,
> 
>> BCS wrote:
>>
>>> Reply to Downs,
>>>
>>>>> R delegate(T) close(R, T...)(R delegate(T) dg)
>>>>> {
>>>>> typeof(dg) res=dg;
>>>>> res.data=res.data.dup; // eventually moves area of stack into RAM
>>>>> return res;
>>>>> }
>>> how will that more stack data into ram? If the delegate gets an array
>>> of pointers to stack frames (or objects) then what you get is a copy
>>> of the pointers that still point into the stack (or objects).
>>>
>> You misunderstand.
>> void[] is not an array of void pointers, but a continuous segment of
>> memory; that being, all the stack the method does access.
>>> If what you have
>>> is a slice of the stack, then what about the next function out? you
>>> will
>>> either still have a reference to another stack frame, or won't have
>>> access to it at all.
>> Not true.
>> The compiler can determine at compile-time which stack frames the
>> function does access. It can then use that data to calculate the
>> pointer
>> (as an offset to the SP) and length of the array.
>>> You might get something with a void[][], but then
>>> you need to do an alloc on each delegate creation, not to mention
>>> Gregor's issue.
>> Yeah, see above. A void[] is sufficient. And Gregor's issue is more of
>> a caveat - I do not believe the cost overhead of delegate _creation_
>> to be a significant problem.
>>
>> Thanks for your feedback :)
>> --downs
> 
> 
> |class Bar { int opApply( int delegate(inout int) dg) {...} }
> |
> |void Fun(Bar b)
> | {
> |  int i;
> |  foreach(inout j ; b)
> |  {
> |    i+=j;
> |    h=0
> |    int nest(inout int k)
> |    {
> |      i+=k;
> |      h-=k;
> |      return 0;
> |    }
> |    b.opApply(&nest)
> |  }
> |}
> 
> 
> There are three nested function here.
> 
> Fun, the foreach body and the nest function
> 
> when the nest function is turned into a delegate in the opApply
> function, the stack looks like this
> 
> Fun
> Bar.opApply  <<<<<
> Fun.foreachBody_1
> 
> potentially, I could add code later that would put an even bigger (or
> smaller) chunk of data between the Fun stack frame and the foreach body
> stack frame. In general this can't be detected at compile time because I
> could do this by deriving a class from Bar.
> 
> 
Again, you're missing something.
The void[] data property I'm proposing does not contain the complete
stack of the delegate. Since part of that stack (the delegate's) doesn't
even EXIST when the delegate is created, this would be rather pointless.
Instead, data references the stack area _outside_ of the delegate that
the delegate uses. So in this case, that would be Fun, directly followed
by its foreach body; two parts of the stack which indeed form a
continuous area.

I hope that clears things up.
 --downs