May 28, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3849



--- Comment #20 from bearophile_hugs@eml.cc 2013-05-28 04:45:25 PDT ---
A small example why enforcing array lengths match improves safety of D programs. This part of a program uses strings to define a binary decision table, but it's easy to make mistakes in the strings:


struct DataPair { string message, truth; }

immutable DataPair[] solutions = [
    {"Check the power cable",                "..#....."},
    {"Check the printer-computer cable",     "#.#....."},
    {"Ensure printer software is installed", "#.#.#.#."},
    {"Check/replace ink",                    "##..##.."},
    {"Check for paper jam",                  ".#.#...."}];


An improvement is to use fixed-sized arrays so the compiler catches some bugs at compile-time:

struct DataPair(uint N) {
    string message;
    immutable(char)[N] truth;
}

immutable DataPair!8[] solutions = [
    {"Check the power cable",                "..#....."},
    {"Check the printer-computer cable",     "#.#....."},
    {"Ensure printer software is installed", "#.#.#.#."},
    {"Check/replace ink",                    "##..##.."},
    {"Check for paper jam",                  ".#.#...."}];


But currently the compiler only gives an error if you add one more char:

    {"Check the power cable",                "..#......"},

And not if you miss one:

    {"Check the power cable",                "..#...."},


And this is not a nice solution also because  most D programmers don's write code like this:

immutable DataPair!8[] solutions = [
    {"Check the power cable",                "..#.....".fixed},
    {"Check the printer-computer cable",     "#.#.....".fixed},
    {"Ensure printer software is installed", "#.#.#.#.".fixed},
    {"Check/replace ink",                    "##..##..".fixed},
    {"Check for paper jam",                  ".#.#....".fixed}];

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3849


Shriramana Sharma <samjnaa@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samjnaa@gmail.com


--- Comment #21 from Shriramana Sharma <samjnaa@gmail.com> 2013-05-31 10:48:29 PDT ---
(In reply to comment #16)
> (In reply to comment #14)
> > 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 :-|

I support the ... syntax to indicate an incomplete array specification for a fixed-size array. Of course, the T[$]= syntax prescribed by bug 481 should not be used with this syntax since they conflict.

1) IMHO absence of a comma between two items inside an array literal should be treated as an error.

2) However, at the end of the specified elements of an array literal, a comma may or may not be present before the ... and it should NOT make any difference -- all the remaining objects should be initialized to T.init. Making a semantic difference on the small distinction between 3,... and 3... would be a bad decision IMHO.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
1 2 3
Next ›   Last »