Hello,

I'm wondering at which moment the following would make an allocation of the scope variables on the GC. Should I assume that the second parameter of enforce being lazy, we would get a delegate/literal that saves the current scope on the GC even if it's not needed? I'm asking purely for a performance perspective of avoiding GC allocations.

void main() {
 int a = 5;
 enforce(true, format("a: %d", a));
}

Thanks

Etienne

On 2/19/23 7:50 PM, Etienne wrote:

void main() {
  int a = 5;
  enforce(true, format("a: %d", a));
}

enforce takes a lazy variable, which I believe is scope by default, so no closure should be allocated.

Indeed, you can't really "save" the hidden delegate somewhere, so the calling function knows that the delgate can't escape.

-Steve

On 2/19/23 9:15 PM, Steven Schveighoffer wrote:

I stand corrected, you can save it (by taking the address of it).

And it's explicitly allowed by the spec.

But.... it still doesn't allocate a closure!

See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627

-Steve

On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote:

So, according to this bug report, the implementation is allocating a closure on the GC even though the spec says it shouldn't?

I've been writing some betterC and the lazy parameter was prohibited because it allocates on the GC, so I'm wondering what the situation is currently

Etienne

On 2/20/23 1:50 PM, Etienne wrote:

The opposite, the delegate doesn't force a closure, and so when the variable goes out of scope, memory corruption ensues.

It shouldn't. Now, lazy can't be @nogc (because that's just what the compiler dictates), but it won't actually use the GC if you don't allocate in the function call.

I just tested and you can use lazy parameters with betterC.

-Steve

On Monday, 20 February 2023 at 19:58:32 UTC, Steven Schveighoffer wrote:

The @nogc issue might be what might be why it didn't work for me. I use it because it's easier to work with betterC but perhaps I should avoid writing @nogc code altogether

Thanks for the info!

Etienne