On 05/28/2014 03:10 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

> On Tue, 27 May 2014 06:42:41 -1000
> Andrei Alexandrescu via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>
>   >
> http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/
>   >
>   > https://news.ycombinator.com/newest (search that page, if not found
>   > click "More" and search again)
>   >
>   > https://www.facebook.com/dlang.org/posts/855022447844771
>   >
>   > https://twitter.com/D_Programming/status/471330026168651777
>
> Fortunately, for the most part, I think that we've avoided the types of
> inconsistencies that Scott describes for C++, but we do definitely have some
> of our own. The ones that come to mind at the moment are:
>
> 1. The order of the dimensions of multi-dimensional static arrays is backwards
> in comparison to what most everyone expects.

However, those expectations are based on the inside-out syntax of C. Naturally, wanting to be consistent, especially compared to C, D should deviate from that syntax.

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

That is sane: It is alwasy "first the type then the size":

int[1]    good
Animal[2] good

Following from that rule (i.e. first type, then size), how would I have an array of 3 elements where each element is an array of 4 elements. Let's see... Each element is int[4]. There:

int[4]

Then, I want an array of 3 of those. There:

int[4][3] good

This is one of the commonish arguments in the D forums that I have the strongest opinion because there is no problem with D's syntax at all. It is consistent.

It is consistent even when indexing. The index is for the array:

int[1] a;
a[0];     // the first element of a; it is an int

int[2][3] b;
b[0];     // the first element of b; it is an int[2]

I don't see any problem at all. :)

Remembering that there is no such thing as a multi-dimensional array in D (nor C), it just follows naturally:

b[0][1];  // the second int of the first int[2]

> is the same as
>
>       int foo[6][5][4];

That's beyond ridiculous. I am glad that D avoided that problem for both function pointers and arrays.

> and has the same dimensions as
>
>       auto bar = new int[][][](6, 5, 4);

That makes perfect sense to me, because this is a function API, not D syntax. There is no ambiguity in saying "you go deeper into the element sizes as you provide the arguments."

Ali

Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies.

I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds.

On Wednesday, 28 May 2014 at 22:42:03 UTC, Ali Çehreli wrote:
> However, those expectations are based on the inside-out syntax of C. Naturally, wanting to be consistent, especially compared to C, D should deviate from that syntax.

I don't get to read the original email, but I agree with the examples you pull out. D's array declaration syntax is so nice. The support for C style syntax is unfortunate though.

On Wednesday, 28 May 2014 at 23:07:07 UTC, Walter Bright wrote:
> Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies.
>
> I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds.

Could you elaborate? Using some of the examples Brian gave, which ones do you think are are mathematically consistent/human inconsistent and which the inverse?

On 5/28/2014 5:35 PM, Brian Rogoff wrote:
> Could you elaborate? Using some of the examples Brian gave, which ones do you
> think are are mathematically consistent/human inconsistent and which the inverse?

Off the top of my head:

    static if (condition)
    else :

    ... declarations ...

All attributes apply to either:

1. the next statement or declaration
2. { ... }
3. : ...

That case is (3), as static if is set up as an attribute.

On Thursday, 29 May 2014 at 00:58:35 UTC, Walter Bright wrote:
> Off the top of my head:
>
>     static if (condition)
>     else :
>
>     ... declarations ...
>
> All attributes apply to either:
>
> 1. the next statement or declaration
> 2. { ... }
> 3. : ...
>
> That case is (3), as static if is set up as an attribute.

Static if is not an attribute.

ConditionalStatement:
    Condition NoScopeNonEmptyStatement
    Condition NoScopeNonEmptyStatement else NoScopeNonEmptyStatement

Condition:
    VersionCondition
    DebugCondition
    StaticIfCondition

Attribute:
    LinkageAttribute
    AlignAttribute
    DeprecatedAttribute
    ProtectionAttribute
    Pragma
    static
    extern
    abstract
    final
    override
    synchronized
    auto
    scope
    const
    immutable
    inout
    shared
    __gshared
    Property
    nothrow
    pure
    ref

On 5/28/2014 6:06 PM, Brian Schott wrote:
> On Thursday, 29 May 2014 at 00:58:35 UTC, Walter Bright wrote:
>> Off the top of my head:
>>
>>     static if (condition)
>>     else :
>>
>>     ... declarations ...
>>
>> All attributes apply to either:
>>
>> 1. the next statement or declaration
>> 2. { ... }
>> 3. : ...
>>
>> That case is (3), as static if is set up as an attribute.
>
> Static if is not an attribute.

They are handled that way by the parser.

https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L379

Looks like there's an omission in the grammar. Thanks for pointing it out.

https://issues.dlang.org/show_bug.cgi?id=12818



>
> ConditionalStatement:
>      Condition NoScopeNonEmptyStatement
>      Condition NoScopeNonEmptyStatement else NoScopeNonEmptyStatement
>
> Condition:
>      VersionCondition
>      DebugCondition
>      StaticIfCondition
>
> Attribute:
>      LinkageAttribute
>      AlignAttribute
>      DeprecatedAttribute
>      ProtectionAttribute
>      Pragma
>      static
>      extern
>      abstract
>      final
>      override
>      synchronized
>      auto
>      scope
>      const
>      immutable
>      inout
>      shared
>      __gshared
>      Property
>      nothrow
>      pure
>      ref

29-May-2014 04:58, Walter Bright пишет:
> On 5/28/2014 5:35 PM, Brian Rogoff wrote:
>> Could you elaborate? Using some of the examples Brian gave, which ones
>> do you
>> think are are mathematically consistent/human inconsistent and which
>> the inverse?
>
> Off the top of my head:
>
>      static if (condition)
>      else :
>
>      ... declarations ...
>
> All attributes apply to either:
>
> 1. the next statement or declaration
> 2. { ... }
> 3. : ...
>
> That case is (3), as static if is set up as an attribute.
>

Static if is certainly NOT an attribute, it doesn't make any sense.
And no, it doesn't matter how the current frontend implements it, because you can argue next to any decisions this way.

-- 
Dmitry Olshansky

29-May-2014 02:10, Jonathan M Davis via Digitalmars-d-announce пишет:
> On Tue, 27 May 2014 06:42:41 -1000
> Andrei Alexandrescu via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>
>  >
> http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/
>  >
>  > https://news.ycombinator.com/newest (search that page, if not found
>  > click "More" and search again)
>  >
>  > https://www.facebook.com/dlang.org/posts/855022447844771
>  >
>  > https://twitter.com/D_Programming/status/471330026168651777
>
> Fortunately, for the most part, I think that we've avoided the types of
> inconsistencies that Scott describes for C++, but we do definitely have some
> of our own. The ones that come to mind at the moment are:

Not talking about other moments, but Unicode kind of caught my eye..
>
> 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.

This is gross oversimplification of the matter. There is no more correct, less correct. Each algorithm requires its own level of consideration, if there is a simple truism about Unicode it is:

Never operate on a single character, rather operate on slices of text.

To sum up the situation:

Unicode standard defines *all* of its algorithms in terms of code points and some use grapheme clusters. It never says anything about code units beyond mapping of code units --> code point. So whether or not you should actually decode is up to the implementation.


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

Agreed. The simple dream of automatically decoding UTF and staying "Unicode correct" is a failure.

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

The worst thing about current situation is any generic code that works on UTF ranges has to jump through unbelievable amount of hoops to undo "string has no length" madness.

I think what we should do is define an StringRange or some such, that will at least make the current special case of string more generic.

-- 
Dmitry Olshansky