static arrays becoming value types

[Steven Schveighoffer]

On Mon, 19 Oct 2009 21:50:46 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Currently, static arrays are (as in C) half-value types and  
> half-reference types. This tends to cause a series of weird problems and  
> special cases in the language semantics, such as functions not being  
> able to return static arrays, and out parameters not being possible to  
> be static arrays.
>
> Andrei and I agonized over this for some time, and eventually came to  
> the conclusion that static arrays should become value types. I.e.,
>
>    T[3]
>
> should behave much as if it were:
>
>    struct ??
>    {
>       T[3];
>    }
>
> Then it can be returned from a function. In particular,
>
>    void foo(T[3] a)
>
> is currently done (as in C) by passing a pointer to the array, and then  
> with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making this  
> change would mean that the entire array would be pushed onto the  
> parameter stack, i.e. a copy of the array, rather than a reference to it.
>
> Making this change would clean up the internal behavior of types.  
> They'll be more orthogonal and consistent, and templates will work  
> better.
>
> The previous behavior for function parameters can be retained by making  
> it a ref parameter:
>
>     void foo(ref T[3] a)

What happens for IFTI?

void foo(T)(T t)
{
    return t[2];
}

void main()
{
    int[3] x;
    x[] = 5;
    printf(foo(x));
}

I would think T would resolve to int[3], which means pass by value.  You'd  
need a specialization for static arrays to get the current behavior.

Don't get me wrong, I would love to see static arrays become real types,  
but I wonder if there are any ways we can "optimize out" the staticness of  
an array argument for templates.  In particular, I hate how IFTI likes to  
assume static array for literals...

In the absence of such an optimization, I'd still prefer static arrays  
become value types like you say.

-Steve