Steven Schveighoffer wrote:
On Fri, 09 Oct 2009 08:34:31 -0400, Don <nos...@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:
// template function
auto x = createArray(a, b, c);
// mixin?
Although the template function looks nice, it adds bloat.
There's no bloat. You just need a type-safe variadic.
T[] createArray(T)(T[] args...);
One function per type. That's the best you're ever going to do with
run-time construction anyway.
Actually, there's horrific bloat present right now. Look at the code
generated when you use an array literal.
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.
There's ambiguity once you leave the simplest cases. See below.
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.
This is exactly the problem.
They should ALWAYS require CTFE evaluation.
EG:
immutable(double)[] tableOfSines = [ sin(0.0), sin(PI/4), sin(PI/2),
sin(3*PI/4), sin(1)];
Obviously, these values should be be compile-time evaluated. But how
does the compiler know that? It can't.
Right now, this is done at run-time.
Runtime array creation is a prime candidate for moving from language to
libraries.
