Array literals' default type

[Don]

Steven Schveighoffer wrote:
> 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:

> // 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.