Array literals' default type

Steven Schveighoffer schveiguy at yahoo.com
Fri Oct 9 05:53:36 PDT 2009


On Fri, 09 Oct 2009 08:34:31 -0400, Don <nospam at nospam.com> wrote:

>
> I don't understand why runtime-determined array literals even exist.
> They're not literals!!!
> They cause no end of trouble. IMHO we'd be *much* better off without  
> them.

I don't agree.  Here is a runtime decided array literal:

void foo(int a, int b, int c)
{
auto x = [a, b, c];
}

The alternatives are:

// manual construction and assignment

auto x = new int[3]; // unnecessary initialization to 0!
x[0] = a;
x[1] = b;
x[2] = c;

// template function

auto x = createArray(a, b, c);

// mixin?

Although the template function looks nice, it adds bloat.  The mixin is  
probably ugly (I don't write them much, so I'm not sure how it would be  
done).  Why shouldn't the compiler just do what you want it to do?  I  
don't see a  lot of ambiguity in the statement above, "I want an array of  
a, b, and c together please".  It's obvious what to do, and the code looks  
clean.

On top of that, what if a, b, and c are runtime decide, then during  
development, or with a new compiler, they can now be CTFE decided?  Now  
you are calling some function when they *could* be in a literal.

It's the same thing in my opinion with range detection.  It used to be  
that:

byte b = 1 + 1;

generated an error, now, it works because the compiler realizes that 1+1  
doesn't overflow a byte.  Why can't we add that same type of smarts into  
array literals?

-Steve



More information about the Digitalmars-d mailing list