New @safe rule: defensive closures

[Steven Schveighoffer]

On 5/28/22 4:12 AM, Dukc wrote:
> 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[]);
> }
> ```
> 

Well, we have to decide if taking a value by ref means it should be 
allocated, or if it should be scope (like DIP1000). If we go with the 
latter, then you start getting error messages, and we are kind of back 
to square one. If we go with the former, then any simple use of struct 
methods is going to allocate a closure.

So yeah, that pretty much destroys this idea.

-Steve