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.
