Array literals REALLY should be immutable

[Don]

I think this is quite horrible. [1, 2, 3] looks like an array literal, 
but it isn't -- it's an array constructor. It doesn't look like a 
function call. It shouldn't be.

Q1. How do you declare an array literal [1,2,3]?
A. It took me four attempts before I got it.

==========================

int main()
{
    immutable int[] x1 = [1, 2, 3]; // NO - not evaluated at compile time
    static int[] x2 = [1, 2, 3];    // NO - uses thread local storage
    enum int[] x3 = [1, 2, 3];      // NO - not indexable at run time.

    static immutable int[] x4 = [1, 2, 3];  // OK
    static const int[] x5 = [1, 2, 3];      // also OK

    for (int i=0; i< 3; ++i) {
        if (x4[i]==3) return i;
    }
    return 0;
}

(x3 is currently accepted, but that's a bug -- the whole point of 'enum' 
is that you can't take the address of it).

This is really ugly and non-intuitive for something so simple. x1 should 
just work.

Q2: How do you create such an array literal and pass it in a function call?
A. ??? Is this even possible right now?

My code is *full* of these guys. For example, function approximations 
use them (look at any of the special functions code in Tango.math, or 
etc.gamma). Unit tests are full of them. Everyone uses look-up tables.

Bug 2356 is a consequence of this.

By constrast, the stupid array constructors we have now can be 
implemented in a trivial library function:

T[] array(T)(T[] x...) { return x.dup; }

I really don't see how syntax sugar for something so simple can be 
justified, at the expense of basic functionality (lookup tables, 
essentially). Especially when it's creating an inconsistency with string 
literals.