http://d.puremagic.com/issues/show_bug.cgi?id=3849

           Summary: [missing error] Array literal length doesn't match
           Product: D
           Version: 2.040
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2010-02-24 01:56:19 PST ---
This small program compiles, but I'd like the compiler to raise a compile error, because I think this is often a bug:

string[4] arr = ["foo", "bar"];
void main() {}

------------

A related enhancement: when I want to define a fixed-sized array with a literal and the number of its items is high, I may not want to count them. In this situation the following syntax can be adopted:

int[$] arr = [10,2,15,15,14,12,3,7,13,5,9,9,7,9,9,9,11,15,1,1,12,5,14];

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #1 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |
                 CC|                            |clugdbug@yahoo.com.au
           Severity|normal                      |enhancement


--- Comment #2 from Don <clugdbug@yahoo.com.au> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #3 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #4 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #5 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com


--- Comment #6 from Stewart Gordon <smjg@iname.com> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #7 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #8 from bearophile_hugs@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #9 from bearophile_hugs@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: -------