New @safe rule: defensive closures

[Dukc]

On Friday, 27 May 2022 at 22:16:30 UTC, Steven Schveighoffer 
wrote:
> Why can't we just do this in `@safe` code whenever it has the 
> same problem? Consider this code snippet:
>
> ```d
> void bar(int[]) @safe;
> void foo() @safe
> {
>    int[5] arr;
>    bar(arr[]);
> }
> ```
> But what if instead, with DIP1000 seeing that, it just says now 
> we have a closure situation, and allocates `foo`'s frame on the 
> heap.

Good brainstorming. But I don't think it can work:

```D
void foo(ref int[5] arr)
{ // It's not up to this function to decide where
   // arr resides in memory. Thus we can't make a
   // closure out of this one without breaking epected
   // behaviour.
   bar(arr[]);
}
```