DIP1000 scope inference proposal

[German Diago]

On Thursday, 27 October 2022 at 00:57:47 UTC, Walter Bright wrote:
> On 10/26/2022 1:03 AM, Walter Bright wrote:
>> On 10/24/2022 6:35 PM, Steven Schveighoffer wrote:
>>> In a `@trusted` function today, without dip1000, the above is 
>>> perfectly reasonable and not invalid. Will dip1000 make it 
>>> corrupt memory?
>> 
>> A very good question. Clearly, having code work when it is 
>> @safe, but cause memory corruption when it is marked @trusted, 
>> is the wrong solution. This should never happen. I'm not sure 
>> what the solution should be here.
>> 
>
> [Some more thinking about the problem]
>
> The question is when is [1,2,3] allocated on the stack, and 
> when is it allocated on the GC heap?
>
> Some points:
>
> 1. in C it is allocated on the stack. D's behavior to allocate 
> it on the heap is kinda surprising in that light, even though D 
> had such literals before C did
>
> 2. allocating on the heap means it is unusable in @nogc code
>
> 3. when writing expressions, the only way to get it on the 
> stack is to assign it to a scope variable, which is 
> inconvenient and inefficient
>
> 4. it runs against the idea that the simpler code should be 
> more efficient than the complex code
>
> Therefore, I suggest the following:
>
>     [1,2,3] is always allocated on the stack
>
>     [1,2,3].dup is always allocated on the heap
>

As a person who has used D but not extensively, I was suprised of 
type[] vs type[N] behavior all the time. I agree that [1, 2, 3] 
should allocate in the stack but I am not sure how much code that 
could break? For example, if before it was on the heap, what 
happens with this now?

int [] func() {
   // Allocated in the stack, I presume that not safe, should add 
.dup?
   int[] v  = [1, 2, 3];
   return v;
}

How it should work?