On Tue, 20 Oct 2009 20:38:33 -0400, Leandro Lucarella <[email protected]>
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.
