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