static arrays becoming value types

[Robert Jacques]

On Tue, 20 Oct 2009 20:38:33 -0400, Leandro Lucarella <llucax at gmail.com>  
wrote:
> language_fan, el 20 de octubre a las 19:19 me escribiste:
>> >> 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?
>
> Yes, thanks for the clarification.
>
>> 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.
>
> Yes, D support for tuples is way far from ideal.

How so? I think this is merely the difference between a library type in a  
flexible language and a built-in type in an inflexible language. I mean  
the example was essentially:
In D:
  Apple a
  Apple b
  Orange c

  assert(a != c); // Error: incompatible types Apple and Orange

In SOL:
  Apple a
  Apple b
  Apple c

  assert(a != c); // ok, both a and c are apples.

Now, if SOL allowed tuples to do things you can't do today in D, like  
assign a tuple to a struct with the same signature, then this might be a  
point. But that wasn't the example given.

Now, the example was a good argument for making it easier and more natural  
to use the built-in tuple type. Adding syntaxtic sugar for tuples has been  
recommended before. I prefer using the slice syntax '..', as it would  
allow clean multi-dimensional slicing and mixed indexing and slicing, both  
of which are important to supporting arrays.