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