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?
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?
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:
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.