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)

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've never heard the argument why they should be value types. Can you or Andrei explain why it makes more sense as value types?

On Mon, 19 Oct 2009 21:50:46 -0400, Walter Bright <newshound1@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)

Thank you. Will the various operators be overloaded? i.e. a = b + c; instead of a[] = b[] + c[]; ?

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> 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)

Vote++.  It's funny, I use static arrays so little that I never realized that they weren't passed by value to functions.  I'd absolutely love to be able to just return static arrays from functions, and often use structs to do that now, but using structs feels like a really ugly hack.

Jason House wrote:
> 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've never heard the argument why they should be value types. Can you or Andrei explain why it makes more sense as value types?

Because they are some bastardization now. Neither slice, nor reference type, nor value type. Somehow, they behave like value type when declared in a struct or a variable. (Because they allocate memory for the contents they point to.) But if you pass them as argument, they behave like reference type (they're just pointers to the actual data). And you can't return them at all from functions for unknown reasons. It's a real WTF.

The only clean way to fix them is the as described by Walter.

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)

WOO! Thanks! :D

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)

Would that be D1&D2 or only D2?

Yes please!

Robert Jacques wrote:
> Thank you. Will the various operators be overloaded? i.e. a = b + c; instead of a[] = b[] + c[]; ?

Don't know. For now, I'd just leave the a=b+c syntax illegal. We can always loosen things up later.

Saaa wrote:
> Would that be D1&D2 or only D2? 

D2 only, as it changes the behavior.