static arrays becoming value types

[Robert Jacques]

On Tue, 20 Oct 2009 22:45:53 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
> Robert Jacques wrote:
>> On Tue, 20 Oct 2009 20:38:33 -0400, Leandro Lucarella  
>> <llucax at gmail.com> wrote:
>>> 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.
>
> I also don't understand all the argument about structural vs. name  
> equivalence.
>
> Andrei

The original thread stated that D's value tuples (as opposed to type  
tuples) were far from ideal, because it's not a built-in type. So two  
people could make value tuple structs types that were incompatible with  
each other. (One counter to this is it's simple to define a templated  
opAssgin method that works correctly. Another counter is to relate this  
problem to typedefs).
My issue was with the example comparing D to some-other-language (SOL).  
The issue was that only the built-in value-tuple type in SOL was shown,  
and not a value-tuple interfacing with something else that wasn't the  
built-in value-tuple. This indicates that SOL isn't flexible/expressive  
enough to have library value-tuple-types, or the problems with D's  
value-tuple type solution.