static arrays becoming value types

Ary Borenszweig ary at esperanto.org.ar
Tue Oct 20 00:31:36 PDT 2009


Walter Bright 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)

I don't know why people are agreeing about this. At least I don't 
understand what the problem is with static arrays. You say:

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

But WHY??? What's the specific problem? I understand that passing things 
by value would solve this, but will hurt performance and it's not in 
sync with "arrays are passed by reference".



More information about the Digitalmars-d mailing list