New @safe rule: defensive closures

[Paul Backus]

On Thursday, 15 February 2024 at 14:48:56 UTC, Dukc wrote:
> So we won't get rid of DIP1000 with this observation, but for 
> sake of consistency maybe we still should reconsider the idea 
> this thread is about.

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.