Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"

via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Thu May 29 02:35:17 PDT 2014


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

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


More information about the Digitalmars-d-announce mailing list