https://github.com/D-Programming-Language/dmd/pull/375

(In reply to comment #1)
> https://github.com/D-Programming-Language/dmd/pull/375

Pull 375 is not about bug 3849 too, right?

Pull 375 does not support `int[$] = [1, 2, 3];`.

(In reply to comment #3)
> Pull 375 does not support `int[$] = [1, 2, 3];`.

OK. This is expected.

Currenly DMD runs code like this (I don't like this, but this is working as designed!):

int[3] arr = [1, 2];
void main() {}


I presume Pull 375 lets this kind of code pass, right?

(In reply to comment #4)
> int[3] arr = [1, 2];
> void main() {}
>
> I presume Pull 375 lets this kind of code pass, right?

??? Pull 375 rejects statically above code, it is expected behavior from this issue.

(In reply to comment #5)

> ??? Pull 375 rejects statically above code, it is expected behavior from this
> issue.

I see. I suggest you to read the whole thread of bug 3849.

Code like the following is working as designed, so if your patch refuses this code, then your patch is implementing an enhancement too (it means it's changing the D specs):

int[3] arr = [1, 2];
void main() {}


Note that I support turning this kind of code into a compile-time error, but Walter (used to) wants it to compile. So at least I suggest your comment of Pull 375 to say this example is now a compile-time error.

(In reply to comment #6)

> Code like the following is working as designed, so if your patch refuses this
> code, then your patch is implementing an enhancement too (it means it's
> changing the D specs):
> 
> int[3] arr = [1, 2];
> void main() {}


Note: For the situations where people want to specify less items than the arrays length I suggested an *explicit* syntax, like:

int[3] arr = [1, 2, ...];
void main() {}

See also:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=144210

(In reply to comment #0)
> The following invalid code is accepted:
> import std.stdio;
> void main() {
>     real[2] foo = [1.0L];
>     writeln(foo);  // [1, 0]
> }

Running it gives:

object.Exception@src\rt\arraycat.d(31): lengths don't match for array copy

(In reply to comment #9)
> (In reply to comment #0)
> > The following invalid code is accepted:
> > import std.stdio;
> > void main() {
> >     real[2] foo = [1.0L];
> >     writeln(foo);  // [1, 0]
> > }
> 
> Running it gives:
> 
> object.Exception@src\rt\arraycat.d(31): lengths don't match for array copy

D is statically typed, so it's better to refuse it at compile-time.

Actually, it would be very cool if D would re-use the integer range trick here and catch all cases that can be proven not to work using it, such that the following code would error at compile time: ;)

int x;
readf("%d",&x);
real[2] foo = 
    x%100>50 ?
    [1.0L, 2.0L, 3.0L][0..2|x&1] :
    ([1.0L, 2.0L] ~ [3.0L, 4.0L] ~ 5.0L)[x&1..$-!(x&1)];

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #0)
> > > The following invalid code is accepted:
> > > import std.stdio;
> > > void main() {
> > >     real[2] foo = [1.0L];
> > >     writeln(foo);  // [1, 0]
> > > }
> > 
> > Running it gives:
> > 
> > object.Exception@src\rt\arraycat.d(31): lengths don't match for array copy
> 
> D is statically typed, so it's better to refuse it at compile-time.


Yes, but that's bug 2547.

As of 2.099, the OP sample properly errors out.

There's still a few issues related to this. For example, issue 19095 still applies, but a PR for it was made and closed due to the effect it had on code.
But closing this as "WORKSFORME" since the other issues are more fine-grained, up-to-date, and have discussions.