[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #14 from Stewart Gordon 2011-09-11 07:50:51 PDT --- (In reply to comment #13) > float[6] arr = [1., 2., 42]; > > This is too much ugly, You don't have to use it then. You could use float[6] arr = [1., 2., 42. ...]; or float[6] arr = [1., 2., 42...]; or float[6] arr = [1., 2., 42.0...]; instead. > so I think it's much better to require a comma before the ellipsis. I made out your intention to be that, with the comma, the remainder of elements would be initialised to the type's .init. A ... following a value without a comma would, OTOH, initialise all remaining elements to the specified value. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #13 from bearophile_h...@eml.cc 2011-09-11 04:11:11 PDT --- (In reply to comment #12) > >> If no item is missing the compiler probably has to generate an > >> error again: > >> > >> int[2] arr = [1, 2, ...]; // compile-time error > > I'm not sure about this. I can imagine someone wanting it to work when the > length is a template parameter, in order to initialise only the first n > members > where n is fixed. I see. > And should we allow a value to precede the ..., like > > int[100] arr = [1, 2, 42...]; > > (all elements beyond the first two initialised to 42)? D allows floating point literals without decimal digits: float[6] arr = [1., 2., 42]; This is too much ugly, so I think it's much better to require a comma before the ellipsis. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #12 from Stewart Gordon 2011-09-10 18:31:01 PDT --- (In reply to comment #11) > See also: > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=144237 > > From that post: > >> The solution is to add some symbol that explicitly marks the array >> as not complete, so both the compiler and the person that later >> reads the code knows some items are missing. >> >> If no item is missing the compiler probably has to generate an >> error again: >> >> int[2] arr = [1, 2, ...]; // compile-time error I'm not sure about this. I can imagine someone wanting it to work when the length is a template parameter, in order to initialise only the first n members where n is fixed. And should we allow a value to precede the ..., like int[100] arr = [1, 2, 42...]; (all elements beyond the first two initialised to 42)? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #11 from bearophile_h...@eml.cc 2011-09-10 02:35:35 PDT --- See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=144237 >From that post: > The solution is to add some symbol that explicitly marks the array as not > complete, so both the compiler and > the person that later reads the code > knows some items are missing. > > If no item is missing the compiler probably has to generate an error again: > > int[2] arr = [1, 2, ...]; // compile-time error > > I think that syntax is explicit and readable enough. A problem with this idea > is > this syntax is probably not > used often. On the other hand leaving that trap > in > the D language is not good at all. > > The idea of the dollar symbol can't be used with the ellipsis symbol: > > int[$] arr = [1, 2, ...]; // compile-time error again > > Note: for me this syntax with $ is more commonly useful compared to the "..." > syntax. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 Gide Nwawudu changed: What|Removed |Added Keywords||accepts-invalid, diagnostic CC||g...@nwawudu.com --- Comment #10 from Gide Nwawudu 2010-11-29 07:39:26 PST --- Real example where the [$] syntax would have been useful. http://www.dsource.org/projects/phobos/changeset/2204 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #9 from bearophile_h...@eml.cc 2010-11-26 12:25:34 PST --- See also bug 481 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849
--- Comment #8 from bearophile_h...@eml.cc 2010-10-28 12:20:43 PDT ---
(In reply to comment #6)
> It isn't an array literal, it's a static initializer. They look the same, but
> are distinct entities with distinct rules.
General design rule: if you want to minimize traps and bugs, then to represent
a different entity you need a different syntax.
Currently this program compiles:
int[4] a = [1, 2, 3];
void main() {}
While this generates:
object.Exception: lengths don't match for array copy
void main() {
int[4] a = [1, 2, 3];
}
This looks like a corner case that's better to remove from D. In this bug
report there are syntaxes that restore the needed flexibility.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #7 from bearophile_h...@eml.cc 2010-08-01 15:29:25 PDT --- See a consequence of this in bug 4565 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 Stewart Gordon changed: What|Removed |Added CC||s...@iname.com --- Comment #6 from Stewart Gordon 2010-05-22 10:12:40 PDT --- It isn't an array literal, it's a static initializer. They look the same, but are distinct entities with distinct rules. See bug 181 and bug 508. This is really a request to change from the fix that was actually applied to the more sensible one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #5 from bearophile_h...@eml.cc 2010-04-27 13:00:32 PDT --- Once the length test is in place, to avoid adding the trailing empty items a very simple ... trailing syntax can be introduced (partially from a suggestion by Michel Fortin): immutable ubyte _ctype[256] = [ _CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL, _CTL,_CTL|_SPC,_CTL|_SPC,_CTL|_SPC,_CTL|_SPC,_CTL|_SPC,_CTL,_CTL, _CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL, _CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL,_CTL, _SPC|_BLK,_PNC,_PNC,_PNC,_PNC,_PNC,_PNC,_PNC, _PNC,_PNC,_PNC,_PNC,_PNC,_PNC,_PNC,_PNC, _DIG|_HEX,_DIG|_HEX,_DIG|_HEX,_DIG|_HEX,_DIG|_HEX, _DIG|_HEX,_DIG|_HEX,_DIG|_HEX,_DIG|_HEX,_DIG|_HEX, _PNC,_PNC,_PNC,_PNC,_PNC,_PNC, _PNC,_UC|_HEX,_UC|_HEX,_UC|_HEX,_UC|_HEX,_UC|_HEX,_UC|_HEX,_UC, _UC,_UC,_UC,_UC,_UC,_UC,_UC,_UC, _UC,_UC,_UC,_UC,_UC,_UC,_UC,_UC, _UC,_UC,_UC,_PNC,_PNC,_PNC,_PNC,_PNC, _PNC,_LC|_HEX,_LC|_HEX,_LC|_HEX,_LC|_HEX,_LC|_HEX,_LC|_HEX,_LC, _LC,_LC,_LC,_LC,_LC,_LC,_LC,_LC, _LC,_LC,_LC,_LC,_LC,_LC,_LC,_LC, _LC,_LC,_LC,_PNC,_PNC,_PNC,_PNC,_CTL, ... ]; This is first of all explicit, and it doesn't clash with C or C99 syntax, it's easy to understand, short, easy to write, compatible with other D syntax. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #4 from bearophile_h...@eml.cc 2010-04-27 10:09:45 PDT --- Walter doesn't want to add the int[$] arr = [...]; syntax: > D is full of syntax, at some point adding more and more syntax to deal > with more and more obscure cases is not a net improvement. > There's a point of diminishing returns. I still think that when a static array literal is given, the compiler has to enforce the length of an array literal to be the same as the specified length. In the uncommon situations where a partial array specification is necessary, the programmer can just add leading empty items. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 --- Comment #3 from bearophile_h...@eml.cc 2010-03-17 12:44:40 PDT --- See related bug 3948 too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849 Don changed: What|Removed |Added Keywords|ice-on-invalid-code | CC||clugd...@yahoo.com.au Severity|normal |enhancement --- Comment #2 from Don 2010-03-16 01:09:43 PDT --- I've moved the ICE in the comment to bug 3974. The original issue is an enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] [missing error] Array literal length doesn't match
http://d.puremagic.com/issues/show_bug.cgi?id=3849
--- Comment #1 from bearophile_h...@eml.cc 2010-02-24 02:10:50 PST ---
This is a similar bug, but the causes seem different (I don't know if in this
case I have to file a new bug report). This program:
void main() {
struct S { int x; }
S[2] a = [{1}, {2}, {3}];
}
Seems to crash DMD with this error message:
Assertion failure: 'j < edim' on line 444 in file 'init.c'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
