On Thursday, 29 May 2014 at 03:29:31 UTC, Jonathan M Davis via Digitalmars-d-announce wrote:
1. The order of the dimensions of multi-dimensional static arrays is backwards
in comparison to what most everyone expects.

    int[4][5][6] foo;

is the same as

    int foo[6][5][4];

and has the same dimensions as

    auto bar = new int[][][](6, 5, 4);

The reasons for it stem from the fact that the compiler reads types outward from the variable name (which is very important to understand in C because of its function pointer syntax but not so important in D). However, once we did

    const(int)* foo;

and didn't allow

    (int)const* foo;

I think that we threw that particular bit of consistency with C/C++ out the window, and we really should have just made static array dimensions be read from left-to-right. Unfortunately, I don't think that we can fix that at this point, because doing so would cause silent breakage (or at minimum, would be
silent until RangeErrors were thrown at runtime).

I don't see this as an inconsistency. Just read it as follows:

    int[6][5]* foo;

- start with the type int
- make an array from it
- make an array from that
- and finally, turn it into a pointer.

    const(int)* bar;

Just read `const(int)` as one entity here (as its form suggests, some kind of "function call"):

- start with a const(int)
- make a pointer from it

3. const, immutable, and inout on the left-hand side of a function declaration are unfortunately legal.

Agreed. At least it's possible to do it by convention (but see 4.).

4. There are some cases (such as with static constructors and unittest blocks) that the attributes have to go on the left for some reason. I don't remember the reasons for it, but it's an inconsistency which definitely trips up even
seasoned D programmers from time to time.

I don't know these cases, but the reason might be is that function declarations and unittests need to be followed by braces (or a semicolon in the case of functions), whereas some other keywords also allow non-compound statements. This could therefore lead to ambiguities as to whether the type qualifier applies to the declaration or the following statement.

5. The fact that pure is called pure is very problematic at this point as far as explaining things to folks goes. We should probably consider renaming it to something like @noglobal, but I'm not sure that that would go over very well given the amount of breakage involved. It _does_ require a lot of explaining

Well, it's just a name, and it's for hysterical raisins ;-) I don't think it's so bad, because the purity concept already differs from language to language.

6. The situation with ranges and string is kind of ugly, with them being treated as ranges of code points. I don't know what the correct solution to this is, since treating them as ranges of code units promotes efficiency but makes code more error-prone, whereas treating them as ranges of graphemes would just cost too much. Ranges of code points is _mostly_ correct but still incorrect and _more_ efficient than graphemes but still quite a bit less efficient than code units. So, it's kind of like it's got the best and worst of both worlds. The current situation causes inconsistencies with everything else (forcing us to use isNarrowString all over the place) and definitely requires frequent explaining, but it does prevent some classes of problems. So, I don't know. I used to be in favor of the current situation, but at this point, if we could change it, I think that I'd argue in faver of just treating them as ranges of code units and then have wrappers for ranges of code points or graphemes. It seems like the current situation promotes either using ubyte[] (if you care about efficiency) or the new grapheme facilities in std.uni if you care about correctness, whereas just using strings as ranges of dchar is probably a bad idea unless you just don't want to deal with any of the Unicode stuff, don't care all that much about efficiency, and are willing have bugs in the areas where operating at the code point level is incorrect.

My preferred solution would be to disallow iterating over bare char/wchar/dchar ranges, but require an explicit .byCodeUnit, .byCodePoint or .byGrapheme. Probably not going to happen, though...

Reply via email to