static arrays becoming value types

[language_fan]

Tue, 20 Oct 2009 12:39:47 -0300, Leandro Lucarella thusly wrote:

> language_fan, el 20 de octubre a las 13:52 me escribiste:
>> 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
> 
> In what tradition? C++ maybe. I never saw a pair type outside C++, but
> saw tuples everywhere (even in other structured languages like SQL).

Pairs are pretty common actually. You might have applications that have 
mappings, functions, or zip (list operation) etc. I admit these are more 
common in functional languages but the main reason for this is that most 
mainstream languages do not support the Pair or Tuple types in any way. 
Even D has broken support (from this point of view).

>> 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.
> 
> I don't understand very well what are you saying anyways...

Because of the unnecessary nominal typing in D's tuple emulation, 
redefinitions of Tuples do not have implicit equivalence relation:

  struct Tuple(T...) {
    T t;
  }
  struct Tuple2(T...) {
    T t;
  }

  void main() {
    Tuple!(int,int) a;
    Tuple!(int,int) b;
    Tuple2!(int,int) c;

    assert(a == b); // ok
    assert(a != c); // Error: incompatible types for ((a) != (b))
  }

In some other language:

  val a = (1,2) : [Int,Int]
  val b = (1,2) : [Int,Int]
  val c = (2,3) : [Int,Int]

  assert(a == b); // ok
  assert(a != c); // ok

Did you get it now?

Real tuple types do not have a special type tag which gets injected 
implicitly with structs. So every time you try to do something 
lightweight by emulating tuples, you need to refer to the global Tuple 
type or bang your head to the wall.