On Thursday, 15 February 2024 at 14:48:56 UTC, Dukc wrote:

No, let's not. This idea is terrible.

Consider: what happens if you're compiling a function with inferred attributes and you encounter some code that escapes the address of a local variable? Do you...

1. Allocate a closure and infer @safe?
2. Not allocate a closure and infer @system?

What if you're compiling code with an explicit @system attribute? Do you still allocate a closure then? What if the programmer wants the less safe, more performant behavior? What about in @trusted code?

Either you consistently use closures everywhere and introduce huge performance regressions into existing @system code, or you end up in a world where the exact same code can have completely different semantics depending on whether it's @safe/@system/@trusted/inferred. I don't think either of those outcomes is acceptable.

On Thursday, 15 February 2024 at 19:35:21 UTC, Paul Backus wrote:

If we're to do either it should be closures everywhere I think.

First I thought that maybe it depends. I frankly don't know what precisely triggers the creation of the closure. If it's done only when the delegate is returned or assigned to the heap or static memory, Is it exactly huge? After all, any code that is returning pointers to locals is returning pointers to expiring stack frames and therefore the code isn't working.

Still, probably there's too much code out there that is assigning the pointers to locals temporarily into the heap. Considering the foundations pledge to favour backwards compatibility, on balance I have to concur with your assesment: a bad idea.

Now another option would be to stop the automatic closure creation for delegates too but that'd be even much bigger breakage. It's not worth any serious consideration. Of the evils we have to pick from, language inconsistency it is.