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


Gide Nwawudu <gide@nwawudu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, diagnostic
                 CC|                            |gide@nwawudu.com


--- Comment #10 from Gide Nwawudu <gide@nwawudu.com> 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: -------

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



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

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



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

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



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

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



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

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


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid             |spec
            Summary|[missing error] Array       |Compiler should catch
                   |literal length doesn't      |incomplete initialisation
                   |match                       |of an array


--- Comment #15 from Stewart Gordon <smjg@iname.com> 2011-09-11 09:45:07 PDT ---
This isn't accepts-invalid, because the current spec allows incomplete initialisation of arrays.  Rather, it's a request to stop accepting these, which later became a request to make the means of partially initialising an array explicit.

-- 
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 #16 from bearophile_hugs@eml.cc 2011-09-13 03:15:30 PDT ---
(In reply to comment #14)

> 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.

Right, but currently D doesn't require such syntaxes to write floating point values, so people are free to write the bad syntax, or you have to add one or more special cases to D.


> 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.

An engineer usually prefers KISS designs, this also means that language
features serve for only one purpose.
The sub-feature you propose is cute, but I think seen from the eyes of an
engineer it risks reducing the value of the whole ellipsis feature :-|

-- 
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 #17 from Stewart Gordon <smjg@iname.com> 2011-09-13 03:38:12 PDT ---
(In reply to comment #16)
> An engineer usually prefers KISS designs, this also means that language
> features serve for only one purpose.
> The sub-feature you propose is cute, but I think seen from the eyes of an
> engineer it risks reducing the value of the whole ellipsis feature :-|

For what more valuable purpose do you wish to save the syntax I proposed? :)

-- 
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 #18 from bearophile_hugs@eml.cc 2011-09-13 04:28:51 PDT ---
(In reply to comment #17)

I have suggested to introduce the "..." syntax for arrays just because Walter thinks global arrays are often initialized partially. Some evidence shows this is a really uncommon need, so maybe it doesn't deserve a special syntax and it doesn't deserve to leave a trap in D that's a confirmed (by Don too) source of bugs. Don also has suggested a library solution that maybe makes "..." useless or less needed.


> For what more valuable purpose do you wish to save the syntax I proposed? :)

The first and main purpose of the "..." syntax is to denote a global/static fixed-sized array that is underspecified (and all items not specified default to T.init).

You propose to add a secondary purpose to the "..." syntax, that allows to specify what's the value of all the not specified items, to ask for a value different from T.init. I have seen not even one use case for this sub-feature, this is bad for this idea.

I my note about engineers I have tried to explain that engineers often have aversion of designs that conflate two different purposes into a single "user interface", especially if one of the purposes isn't a confirmed need and if it creates problems when it's used alongside other features (floating point numbers without leading digits). So I fear that the appreciation of Walter of this idea is _decreased_ by the idea of adding this sub-feature.

-- 
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 #19 from bearophile_hugs@eml.cc 2013-03-27 06:28:32 PDT ---
The fix for Issue 9712 offers a workaround for this D design mistake:


T[n] fixed(T, size_t n)(T[n] a) { return a; }

string[3] colors1 = ["red" "green", "blue"]; // Wrongly accepted.

string[3] colors2 = ["red" "green", "blue"].fixed; // Refused.

void main() {}

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