DIP1000 scope inference proposal

[Quirin Schroll]

On Thursday, 27 October 2022 at 09:36:25 UTC, German Diago wrote:
> 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:
>> ```d
>> [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?
> ```d
> 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?

If `[1, 2, 3]` is stack allocated, it should not compile (at 
least not in `@safe` code, probably not in `@system` code 
either). The problem is not the assignment to `v` (that is of the 
same kind as a pointer to a local variable), but that its value 
is returned and thus leaking the address of a local.