DIP1000 scope inference proposal

[Steven Schveighoffer]

On 10/27/22 9:44 AM, Walter Bright wrote:
> On 10/26/2022 6:26 PM, Steven Schveighoffer wrote:
>> Please no! We can allocate on the stack by explicitly requesting it:
>>
>> ```d
>> int[3] = [1, 2, 3];
>> ```
>>
>> The issue is the DRYness of it. This has been proposed before, just:
>>
>> ```d
>> int[$] = [1, 2, 3];
>> ```
> 
> How would this be done:
> 
>      foo([1,2,3] + a)

Already works today, except I don't know what the + a means:

foo([1, 2, 3].staticArray);

>> If we are going to fix something, let's fix this! It's backwards 
>> compatible too.
>>
>> If anything, the compiler can just punt and say all array literals 
>> that aren't immediately assigned to static arrays are allocated on the 
>> heap. Then it's consistent.
> 
> And inefficient.

Inefficiencies that are taken care of by modern backends, such as llvm 
and gcc.

>> Allocating array literals on the heap is *awesome*, please don't 
>> change that! D is one of the best learning languages for 
>> high-performance code because you don't have to worry at all about 
>> memory management out of the box. I'm actually OK with backends using 
>> stack allocations because it can prove they aren't escaping, why can't 
>> we just rely on that?
> 
> I thought your test case showed the problem with that :-/
> 

Backends that put it on the stack are not using language constructs such 
as scope to make assumptions, they are using actual analysis of the 
control flow to prove that it doesn't escape.

-Steve