static arrays becoming value types

Robert Jacques sandford at jhu.edu
Wed Oct 21 08:07:29 PDT 2009


On Wed, 21 Oct 2009 02:23:09 -0400, language_fan <foo at bar.com.invalid>  
wrote:
> Tue, 20 Oct 2009 16:25:05 -0400, Robert Jacques thusly wrote:
>
>> On Tue, 20 Oct 2009 15:19:15 -0400, language_fan <foo at bar.com.invalid>
>> wrote:
>>
>>> 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.
>>
>> Or use a templated opAssign mixin to allow two desperate types to be
>> assigned to each other.
>
> Wow, you need templates to implement == for built-in values types, nice..

Unlike C++, D templates don't require a PhD to use. And it's definitely  
better that banging your head against the wall.

>> Besides, I think you're comparing apples to oranges. In the SOL example,
>> you use the same declaration for all types. Shouldn't the SOL example
>> be:
>>
>>    val a = (1,2) : [Int,Int]
>>    val b = (1,2) : [Int,Int]
>>    val c = (2,3) : MyCustomTupleType[Int,Int]
>>
>> which would probably generate:
>>       assert(a == b); // ok
>>       assert(a != c); // Error: incompatible types for ((a) != (b))
>
> If you have built-in tuple literals, there is no way you can build a
> MyCustomTupleType without resorting to other language features. There are
> no apples and oranges, cause they both are seen as (Int,Int) by the
> equivalence checker. Do you understand how equivalence works in
> structural typing system (http://en.wikipedia.org/wiki/
> Structural_type_system) vs nominal typing? In structural equivalence
> there are no names attached to the types (well there might be, but those
> are omitted in the comparison), only their internal structure matters.
>
> Why would anyone want to create two incompatible tuples by default as you
> still would have 'typedef' and 'struct' for implementing just that.

My issue was that all your example _showed_ was nominal typing. Though I  
didn't mention it by name, I did mention that if SOL tuples had structural  
typing, it might would be a different story. (Well, until/if  
opImplicitCast was implemented, as it would allow for structural typing.)





More information about the Digitalmars-d mailing list