On Thursday, 14 July 2022 at 19:57:24 UTC, Basile B. wrote:

dmd already comes very close, though:

unittest {
    int[2] arr = [1, 2, 3];
}

This fails to compile with "Error: mismatched array lengths, 2 and 3". So, treat $ in int[$] like it's a random number, which already works, but then when you get to checking the lengths, accept 3 as the length of the array.

On Thursday, 14 July 2022 at 17:46:18 UTC, Dave P. wrote:

There was a DIP for it, but the author withdrew it. Anyone is free to pick up where he left off:

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md

On Thursday, 14 July 2022 at 14:37:34 UTC, ryuukk_ wrote:

C# certainly has it and since 7.0 they can be called from safe contexts with Span<> types, your expectations can be fulfilled with

   Span<int> arr = stackalloc int[] {1, 2, 3};

Godbolt link, https://godbolt.org/z/6b6MMPe7v

While Java is getting them when Valhala finally gets integrated.

On Friday, 15 July 2022 at 02:14:53 UTC, Mike Parker wrote:

I can hear Walter yelling for the DIPs 7 years ago: Again? No!

It was written by Walter 10 years ago 😀

SDB@79

On Friday, 15 July 2022 at 05:50:33 UTC, Paulo Pinto wrote:

   Span<int> arr = stackalloc int[] {1, 2, 3};

It's a very long C# code, but they're right on this rationale for D:

SDB@79

On Friday, 15 July 2022 at 06:17:26 UTC, Salih Dincer wrote:

But now you can just point out that C++ does it...

On Thursday, 14 July 2022 at 13:30:58 UTC, jfondren wrote:

And this also should be killed with fire. We need a clean distinction between static arrays, GC-controlled dynamic arrays, and slices.

On Saturday, 16 July 2022 at 15:12:19 UTC, Ogi wrote:

Correct but that's just one out of many examples where C++ is simply better designed. C++'s references work better than D's inout, C++'s const system works better as it allows for reference counted containers ("logical constness"), D's postblits had to be replaced with copy constructors (like C++ does it), shared doesn't mean anything (C++ lacks it), D's class construct introduces a value vs pointer semantics schism that C++ consciously avoided, D's class construct comes with a monitor (C++ does not have this overhead), C++ does not misuse the enum keyword, C++ lacks an effect system like @nogc @safe @etc that simply gets in the way, C++ doesn't need "interface", it allows for multiple inheritance instead so that's an entire entity that it lacks as it doesn't need it.

Now you can disagree with this list all you want and point out details which I got wrong but the point here is: Don't be surprised that D never really replaced C++, it's not the lack of marketing and it's not the lack of manpower either, the language is not designed all that well and it didn't learn much from C++.

On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

int[3] arr = [1, 2, 3]

TDPL book deals with this question. Andrei said that "experience with pascal" shows it's better to be dynamic by default.

Otherwise it would have to be either immutable or impure. Consider:

@safe pure int[] fun()
{ auto arr = [1, 2, 3];
  return arr;
}

@safe void main()
{ import std.stdio;
  auto arr1 = fun();
  foreach(ref el; arr1) el += 3;
  auto arr2 = fun();
  foreach(ref el; arr2) el += 10;
  arr1.writeln;
  arr2.writeln;
}

GC allocation is the only way this can work. If arr was allocated from static data, the two calls to fun would refer to the same array, meaning the output would be

[11, 12, 13]
[11, 12, 13]

. fun would not be pure at all!

arr in fun also can not be stack allocated, because stack allocations can last only until the function that allocated returns. arr is returned, meaning it needs to continue existing beyond returning from fun.