Array literals REALLY should be immutable

[Eldar Insafutdinov]

Don Wrote:

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

I agree too. that will be consistent.