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
<[email protected] <mailto:[email protected]>>:
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
