New @safe rule: defensive closures

[Dukc]

On Thursday, 15 February 2024 at 19:35:21 UTC, Paul Backus wrote:
> 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.

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.