Should we remove int[$] before 2.067?

[Meta via Digitalmars-d]

On Friday, 30 January 2015 at 20:43:10 UTC, Andrei Alexandrescu 
wrote:
>> I think if you showed someone auto declarations and then 
>> showed them
>> something like auto[] arr = [...], their likely reaction would 
>> be "well
>> of course that works". Although maybe I'm too familiar with D 
>> at this
>> point and that's not the case at all.
>
> Yah, that's nice but needs appropriate formalization. How about 
> auto[auto] to ensure an associative array type, or Xyz!(auto, 
> auto)

staticArray!(int, auto) sarray = [1, 2, 3];

Maybe it is more general and powerful. Also, I believe that Kenji 
*did* implement auto[auto]. I'm assuming you were just giving 
examples and not seriously proposing the above, though.

> to ensure template Xyz with exactly two arguments, or even 
> auto!(auto) to match any template instantiated with one 
> argument...?

All interesting ideas.

> It's just getting weird, and not very useful because it's 
> impossible to associate names with those "auto"s. As I 
> mentioned this is sometimes used in C++ but I don't see vital 
> idioms. I see people sometimes use
>
> auto& a = arr[n];
>
> to make sure they take a reference, but we can't define 
> references locally so we can't use that :o).

I am having difficulty thinking of a situation where you want to 
refer to the auto from something like `int[auto]`. Are you 
alluding to pattern matching? I do agree that pattern matching is 
much more powerful, general, and useful then a partial 
type-deduction feature. I will also point out that partial type 
deduction for templates, AKA higher-kinded types, has been a 
great success in D, and it would be great to bring that power 
into other areas of the language.

This is really all just pleasant diversion thinking about what 
could be, but I  think we can all at least agree that it will not 
be a huge blow to D if [$] or partial type deduction gets 
reverted. This is in spite of the fact that I like the latter, of 
course.