Array literals are weird.

[Blatnik]

On Saturday, 1 May 2021 at 15:14:49 UTC, Mike Parker wrote:
> I strongly disagree. That array literals produce dynamic arrays 
> made sense to me from the day I found D, and it still makes 
> sense 18 years later.

I really can't argue here. If you just want to not think about 
it, then having it always be dynamically allocated is the way to 
go.

But isn't D a systems level programming language where you _do_ 
want to care about things like what is dynamically allocated and 
what isn't? :D

If so then the language should encourage you to allocate 
statically wherever possible. At least in my view.

> If they were to produce static arrays, then what happens here?
>
> ```d
> int[] a = [1, 2, 3];
> return a;
> ```

Well the way I saw my idea working is that the compiler would 
give you a hard error here, and tell you to fix it by allocating 
it with `return a.dup` if that's what you wanted, or make the 
function return a static array if _that's_ what you wanted.

> And what about this?
>
> ```d
> doSomeMatrixStuff3x3(
>     [1.0, 0.0, 0.0,
>      0.0, 1.0, 0.0,
>      0.0, 0.0, 1.0]
> );
> ```
>
> Now I'm passing 9 floats by value unless I remember to do 
> whatever needs to be done to indicate that this should be 
> dynamic (`.dup`).

Unless `doSomeMatrixStuff3x3` does something stupid like copying 
the slice to a global variable, then you don't need to 
dynamically allocate the temporary before you pass it in anyway. 
So if the array literals were static, the compiler would turn the 
call above into something like:

```D
float[9] __temporary = [1, 0, 0, 0, 1, 0, 0, 0, 1];
doSomeMatrixStuff3x3(__temporary[]);
```

This is what you end up doing in -betterC and @nogc anyway, and 
without them this will still save you an unnecessary allocation.

Note that if `doSomeMatrixStuff3x3` _does_ save the slice to a 
global variable or something, that's already incorrect today, as 
you could in theory pass in a stack allocated static array as a 
slice (exactly like it is being called above).

> Moreover, I really would hate to see either `@nogc` or BetterC 
> have any impact on language changes. Those are the 
> *exceptional* cases. D is a GC'ed language. `@nogc` and BetterC 
> are more restricted subsets.

I see your point. This change would make code without @nogc 
slightly more annoying to write because of the error messages 
when you try to do something like the above, which is fine to do 
right now.

But I guess in my view this could be a (slightly) helpful change 
for (every subset of) the language.