Voldemort declarations inside structs with ctor initialization

Idan Arye via Digitalmars-d digitalmars-d at puremagic.com
Tue May 27 23:20:27 PDT 2014


On Wednesday, 28 May 2014 at 02:05:43 UTC, Meta wrote:
> On Tuesday, 27 May 2014 at 23:18:12 UTC, Idan Arye wrote:
>> Well, it won't work for the example that opened this 
>> thread(converted to use lambdas).
>>
>> As for limiting the delegate version to ones that use @pure 
>> and @nogc, take another look at my example. The lambdas don't 
>> allocate anything so they're obviously @nogc. As for @pure, 
>> they doesn't have any side effects, and depend only on their 
>> arguments(they don't have arguments, and they are constant 
>> functions) and their scope(which happens to be mutable, but 
>> you could easily make it immutable and nothing will change).
>
> Delegates by default allocate a closure. If they're marked 
> @nogc, they'd be unable to allocate that closure... I think. 
> The pure annotation is to stop them from accessing global 
> mutable state.

 From what I know(don't know how it is implemented in D. I know it 
doesn't work that way in languages that emulate closures like C++ 
and Java) delegates don't "allocate a closure" - rather, they use 
a the callstack frame that was already allocated by the function 
as a closure. While it's true that they have to save a reference 
to that frame, there is no separately GCed memory for saving that 
reference - it's stored in the fat pointer together with the 
function pointer.

Either this or that - it doesn't affect @nogc. @nogc means that 
when you *run* the function no GCed memory is allocated. Whatever 
memory allocated for the closure(and the function pointer! which 
regular `function`s also have!) is allocated when you *create* 
the delegate.


The lambdas in my example don't allocate any memory when you 
*run* them.

Any lambda - with or without closure - needs to allocate memory 
when you *create* it.


At any rate, a delegate without a closure is either a 
`function`(which can be body-hashed without any problem) or a 
method(which doesn't need body-hashing), so having the @nogc 
restriction would be pointless even if @nogc prevented closures. 
And when I think about it, I also fail to understand why you 
suggest the @pure restriction - the problem in body-hashing is 
what the identifier refer to, not what the lambda does with it...


More information about the Digitalmars-d mailing list