As discussed in this forum, Kenji has authored https://github.com/D-Programming-Language/dmd/pull/3615 which has been recently merged.

By this I am proposing we revert that decision, and quickly - before 2.067 is released lest we'll need to support it forever. Here's why.

One simple litmus test for a new language feature is "it can't be done within the current language". That's a good yardstick; coupled with the importance of the task, it forms a compelling reason for adding the feature. There's nuance to that, e.g. it can be done but it's onerously difficult; or the feature is so frequently needed, dedicated language is warranted.

The recent int[$] feature seems to fail that test. That feature, and in fact more, can be done trivially with library code:

http://dpaste.dzfl.pl/f49a97e35974.

In my opinion these particular features are not frequent enough to warrant dedicated syntax.

Furthermore, one other unpleasant aftermath of int[$] is that new syntax begets more new syntax. The proverbial ink was not yet dry on the #3615 merge when a new, new syntax was proposed in this forum, this time for statically-allocated statically-sized arrays. Far as I can tell the main argument is "you have to write longer code" without it.

I am not okay with that - at all.

D is a great language with many awesome features. Too many, in some people's opinion. We must get into the habit of using D's ample orchestra to create new music, not add a new instrument for every tune.

So I am think we should consider reverting https://github.com/D-Programming-Language/dmd/pull/3615 and adding the appropriate functions to std.array.

Please advise.


Andrei

On 30/01/2015 14:47, Andrei Alexandrescu wrote:
> The recent int[$] feature seems to fail that test. That feature, and in
> fact more, can be done trivially with library code:
>
> http://dpaste.dzfl.pl/f49a97e35974.

+1. Also discussed here:
https://issues.dlang.org/show_bug.cgi?id=8008#c8

2015-01-30 23:47 GMT+09:00 Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com>:

> Please advise.


The new feature, I call it "Partial type deduction", is not only for static
array length.
Examples:

void main()
{
    const[] a1 = [1,2,3];   // a mutable array of const ints
    static assert(is(typeof(a1) == const(int)[]));
    a1 ~= 4;                // OK
    static assert(!__traits(compiles, { a1[0] = 10; }));     // cannot
modify const

    immutable[][$] a2 = [[1,2], [3,4]];  // a static array of mutable
dynamic array of immutable ints
    static assert(is(typeof(a2) == immutable(int)[][2]));
    static assert(!__traits(compiles, { a2 ~= [[5,6]]; }));  // cannot
append to static array
    a2[0] = [7,8];          // OK
    assert(a2 == [[7,8], [3,4]]);
    static assert(!__traits(compiles, { a2[0][0] = 100; })); // cannot
modify immutable
}

The type deduction will provide powerful way to type variables.
Yes, ultimately they can be replaced with library function calls, but the
call will be ugly and hard to understand. Consider making a2 by using
library function. Can you show us a concept design for that?

And, staticArray function will not work for the following case:

int function(int)[$] funcs = [
    a => a + 1,
    a => a * 2,
];

The template lambdas have no type until they applied to the type `int
function(int)`. So

auto funcs = staticArray(
    a => a + 1,
    a => a * 2,
);

is clearly impossible.

The core of the feature is a pattern matching for the declared variable type. I believe it will be useful for declarative style programming.

Kenji Hara

On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:
>      immutable[][$] a2 = [[1,2], [3,4]];  // a static array of mutable
> dynamic array of immutable ints
>      static assert(is(typeof(a2) == immutable(int)[][2]));
...
> The type deduction will provide powerful way to type variables.
> Yes, ultimately they can be replaced with library function calls, but the
> call will be ugly and hard to understand. Consider making a2 by using
> library function. Can you show us a concept design for that?

auto a2 = staticArray!(immutable(int)[])([1,2], [3,4]);

This version of staticArray allows the user to (optionally) specify the element type.

> And, staticArray function will not work for the following case:
>
> int function(int)[$] funcs = [
>      a => a + 1,
>      a => a * 2,
> ];
>
> The template lambdas have no type until they applied to the type `int
> function(int)`. So

auto funcs = staticArray!(int function(int))(
      a => a + 1,
      a => a * 2,
    );

2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d < digitalmars-d@puremagic.com>:

> This version of staticArray allows the user to (optionally) specify the
> element type.


How the API can replace following declaration with ?

auto[$][][$] = [
    [[1,2]],
    [[3,4], [5,6]],
    [[7,8], [9,10], [11,12]],
];

On 30/01/2015 17:01, Kenji Hara via Digitalmars-d wrote:
> 2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d <
> digitalmars-d@puremagic.com>:
>
>> This version of staticArray allows the user to (optionally) specify the
>> element type.
>
>
> How the API can replace following declaration with ?
>
> auto[$][][$] = [
>      [[1,2]],
>      [[3,4], [5,6]],
>      [[7,8], [9,10], [11,12]],
> ];

alias s = staticArray;
auto arr = staticArray(
      [[1,2].s],
      [[3,4].s, [5,6].s],
      [[7,8].s, [9,10].s, [11,12].s],
 );

On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:
> The new feature, I call it "Partial type deduction", is not only for static
> array length.

Yes, I think the other improvements are useful, but [$] is not strictly necessary. Maybe [$] will turn out to be worth having, but I'm not sure that's clear yet.

On 30/01/2015 16:53, Nick Treleaven wrote:
> This version of staticArray allows the user to (optionally) specify the
> element type.

Actually, I'm having trouble implementing staticArray like that, perhaps there are compiler issues causing problems. Using this:

T[len] staticArray(T, size_t len)(T[len] items)
{
    return items;
}

you would need to call it: staticArray([a, b, c]). UFCS doesn't seem to work, and I can't get the immutable or function array example to compile either (with the extra [brackets])...

On Fri, Jan 30, 2015 at 06:47:22AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> As discussed in this forum, Kenji has authored https://github.com/D-Programming-Language/dmd/pull/3615 which has been recently merged.
> 
> By this I am proposing we revert that decision, and quickly - before 2.067 is released lest we'll need to support it forever. Here's why.

If it wasn't a good idea, I don't have a problem with reverting it, but what I'm wondering is, why raise the objection *now* rather than *months* ago when the PR was sitting in the queue idle? From the discussion on github, it appeared that the only objection against it was that Walter didn't like the syntax. Where were the arguments about it being a superfluous syntax change? Why raise the objections now rather than back then?

I think we need to improve the process here. If a PR is not up to par or is a bad idea, or approval from Walter/Andrei is required, can we pretty please mark it as such beforehand? Rather than, as it would appear, let it sit there until someone merges it, only to parachute in after the fact to blast it to bits? (I know that's not the intention, but that's what it looks like, since I've lost count of how many months this particular PR was sitting in the queue with only minor nitpicks raised against it and no sign of imminent doom like it's made out to be now.)


T

-- 
This is not a sentence.

On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu wrote:
> So I am think we should consider reverting https://github.com/D-Programming-Language/dmd/pull/3615 and adding the appropriate functions to std.array.
>
> Please advise.

+1
Woah, please stop adding syntax and focus on stability, libraries and interoperability.

We don't want the situation of C++ where people only use 80% of it's features and that 80% is different for everyone. I've recently been writing some Go code and it's become clear to me just how big of a language D really is.