static arrays becoming value types

[language_fan]

Tue, 20 Oct 2009 10:34:35 -0300, Leandro Lucarella thusly wrote:

> dsimcha, el 20 de octubre a las 02:44 me escribiste:
>> == Quote from Walter Bright (newshound1 at 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.
> 
> It would be the poor men tuple for returning (homogeneous) stuff =P

It depends on how you define things. Traditionally tuples are seen as a 
generalization of pairs (2 elements -> n elements). Records, on the other 
hand, are generalization of tuples (simple number index -> named 
elements). You need couple of additional layers of generalization to come 
up with structs (subtyping, member functions, generics etc.)

One nasty thing about D's structs is that they don't have structural 
equivalence relation unlike tuples. So you need to use the same container 
struct type to get the same semantics. To achieve that you would need 
some kind of STuple on standard library level or other kinds of hacks.

What I find unfortunate in D is that your abstractions come in two sizes 
- either you use the modest tiny construct that does not scale elegantly 
or the enormous hammer to crush things down theatretically.