Should we remove int[$] before 2.067?

[Andrei Alexandrescu via Digitalmars-d]

On 1/30/15 9:01 AM, Kenji Hara via Digitalmars-d wrote:
> 2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at 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]],
> ];

This is interesting, and something we might get behind if it has general 
power. I'll note that partial deduction with "auto" is done in C++ and 
occasionally useful.

We should definitely support "const[] a1 = [1, 2, 3];" regardless of the 
general decision about [$].

Where I have more difficulty is understanding how e.g. matching may help 
in a function call context, or how it generalizes beyond inferring sizes 
for statically-sized arrays (which I'd say is a rather dull category of 
cases).

One other aspect is the more complex the array shape, the more awkward 
it becomes with library functions; however, the frequency of use or even 
necessity also decrease correspondingly.

One extra note - the original feature request 
https://issues.dlang.org/show_bug.cgi?id=481 was made in November 2006. 
At that time, common library artifacts such as CommonType did not exist 
and were at most a dream of the future; with what we have now doing 
everything needed takes a couple of lines. It looks like we've lost 
perspective.

Walter and I don't feel all too strongly about this so we wanted to 
gauge good signal from the dlang brass. We have a few roads from here:

1. Convince ourselves that [$] has current and future benefits that are 
larger than what library code can ensure reasonably, and do nothing - 
i.e. keep the feature starting with 2.067.

2. Release the feature but consider it experimental; don't document it, 
or mention it may be removed in future releases.

3. Release the feature and make it opt-in via a DIP (-dip=xxx) that 
would motivate it properly.

4. Undo the pull request at least for now, and get to the design table 
to make sure it's worth the added cost.

One road I want explicitly not taken is:

5. This feature is the first of a cornucopia of custom annotations for 
various related cases.

I am particularly worried by the near-instant use of this feature as a 
precedent for proposing more similar ones. We must stop that.


Andrei