Bug 5290 – Static array literals with too few elements

Status
RESOLVED
Resolution
WORKSFORME
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
Other
OS
Windows
Creation time
2010-11-29T05:55:24Z
Last change time
2022-03-10T06:23:19Z
Keywords
accepts-invalid
Assigned to
No Owner
Creator
David Simcha
See also
https://issues.dlang.org/show_bug.cgi?id=3849

Comments

Comment #0 by dsimcha — 2010-11-29T05:55:24Z
The following invalid code is accepted: import std.stdio; void main() { real[2] foo = [1.0L]; writeln(foo); // [1, 0] }
Comment #1 by k.hara.pg — 2011-09-09T09:35:47Z
Comment #2 by bearophile_hugs — 2011-09-09T10:29:30Z
(In reply to comment #1) > https://github.com/D-Programming-Language/dmd/pull/375 Pull 375 is not about bug 3849 too, right?
Comment #3 by k.hara.pg — 2011-09-09T10:40:55Z
Pull 375 does not support `int[$] = [1, 2, 3];`.
Comment #4 by bearophile_hugs — 2011-09-09T11:00:10Z
(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?
Comment #5 by k.hara.pg — 2011-09-09T11:23:57Z
(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.
Comment #6 by bearophile_hugs — 2011-09-09T11:31:56Z
(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.
Comment #7 by bearophile_hugs — 2011-09-09T11:34:38Z
(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() {}
Comment #8 by bearophile_hugs — 2011-09-09T11:52:16Z
Comment #9 by bugzilla — 2012-01-20T12:57:27Z
(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
Comment #10 by bearophile_hugs — 2012-01-20T15:08:36Z
(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.
Comment #11 by timon.gehr — 2012-01-20T15:38:41Z
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)];
Comment #12 by clugdbug — 2012-01-24T06:29:05Z
(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.
Comment #13 by pro.mathias.lang — 2022-03-10T06:23:19Z
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.