NotNull pointers

[Jonathan M Davis]

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