On Tuesday, August 30, 2011 09:35 Andrei Alexandrescu wrote:
> On 8/29/11 7:49 PM, bearophile wrote:
> [snip]
>
> > void main() {
> >
> > auto a = new nFoo[5];
> > bar(a[0]);
> >
> > }
>
> Ah, that reminds me. The introduction of @disable requires the
> introduction of array-with-constructor syntax that has long been
> proposed to both C++ and D:
>
> new Type[n](argument1, argument2, ..., argumentn)
>
> creates an array of Type of size n. Each element is constructed with
> argument list (argument1, argument2, ..., argumentn).
That particular syntax does kind of fly in the face of discusssions to remove
new Type[n] in favor of requiring new Type[](n). And even if that's not
considered a problem, how does that interact with multi-dimensional arrays?
e.g. new Type[][](4, 5)? Or does it just not make sense with multi-dimensional
arrays?
I suppose that we could just say that a second set of parens is required. So,
new Type[n](args) works as long as we have new Type[n](args), and new Type[]
(n)(args) works for the case where you put the size in the parens (as arguably
should be required). Then if it supported multi-dimensional arrays, it would
be something like new Type[][](4, 5)(args), though I'm not quite sure how
you'd really support it in multidimensional arrays except perhaps something
like new Type[][](4, 5)((args1), (args2), (args3), (args4)) - where each argsX
is a full arguments list for each inner array. That's arguably pretty ugly
though. However, I don't see any other way to support multi-dimensional arrays
if we want to.
Regardless, the issue of how to properly distinguish between the current new
Type[](n) and the the array-with-constructor syntax. And I'd _love_ to see new
Type[n] die, given the confusion that it causes when going to multi-
dimensional arrays. But assuming that we can't do that, we should at least
make sure that there's no ambiguity with new Type[](n).
- Jonathan M Davis
