It is misleading, nobody expect this to be GC allocated

It should be equal to:

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

Also why it is GC allocated without requiring new?

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

People expect that who try to append to it later on in the function. The book "Learning D" really emphasizes stuff like this, useful but potentially surprising parts of the native types of the language.

All languages have stuff like this. D has a performance hazard in treating dynamic arrays like stacks; Go avoids that while having the fun design where appending to a slice might modify a different slice.

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

D doesn't have a principle like "GC allocations should all be signposted with new". These visual-signposting principles are neat and all, but as long as the language has pervasive function-calling, every single one can violate the principle. What D does have is @nogc

https://dlang.org/spec/garbage.html#op_involving_gc

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

Then the compiler should tell them that it is a static array and they should be explicit if they want to append

Corner cases from clueless people shouldn't make the default useless and misleading

I disagree hard, not "all languages have stuff like this" D has stuff like this

Maybe Java/C# but they don't have the concept of static arrays, again, who's the target audience of D?

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

It is a mistake then

Little rant:

As time goes by, i'm thinking more and more to finally learn language programming and fork D to get rid of all these stuff that makes me want to look for an alternative language

Every once in a while i get reminded why i had that thought, thanks to issues i encounter like this one, very frustrating when you take into account that nobody wants new features and instead want to rely on template soup indefinitely

static arrays? just use

 import std;
 auto arr staticArray!int(1,2, 3);

"no need to change the language"

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

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

Maybe I'm not fully awake, but why would anyone expect this to not be GC allocated?

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

Instead of the compiler telling those clueless people that their expectations were wrong, it's telling you that your expectations are wrong. And you want me to have no sympathy for people like that? I mean, if you really want that, OK:

It has to be one way or the other, and it's the way it is, and it's useful and it makes sense. Dynamic arrays are a high-convenience feature, so convenient you don't even have to care about their storage, and they're very naturally preferred by the convenience feature of not even having to say what type a value has.

Static arrays are still very nice in D, especially their array ops https://dlang.org/spec/arrays.html#array-operations , but they require extra care in more ways than this.

On Thursday, 14 July 2022 at 14:51:01 UTC, bachmeier wrote:

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

Similar syntax in C is for a static array of inferred length:

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

D has no way to express a similar concept without being horribly verbose with .staticArray.

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

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

auto is like a politician speaking with big promises. Unless you explicitly state it, you have to accept its choice. For example:

void main()
{
  alias type = int[3];
  auto arr = cast(type)[1, 2, 3];
  assert(is(typeof(arr) : type));
}

It usually chooses int for numbers, its arrays are dynamic.

SDB@79

On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

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

ehh, isn't that a C99 feature? I'm still waiting for compilers to support it.

D has support for the older way of needing a redundant length, and D errors out if the length is wrong in most cases. Still, I also wanted inferred length with a feature like int[_] arr.

There are little conveniences like this where D's losing out against the state out of the art in 'older' languages: C got inferred length, C has named-member struct literals that D doesn't like, C++ has structured bindings.

Also:

enum nums = [1, 2, 3];
int[nums.length] arr = nums;

I'd never do exactly that, but keeping n array in compile-time and only statically picking from it is an option, with @nogc protecting you from accidentally building it.

On Thursday, 14 July 2022 at 16:50:40 UTC, jfondren wrote:

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

It’s a C89 feature, it’s in my copy of The C Programming language.

On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

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

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

That would be a potential justification. OP claims nobody would expect a dynamic array, though, and matching C's behavior hardly makes the design choice obvious.

OP wanted it to act the same as int[3] arr = [1, 2, 3], so clearly there is.