On Tue, 20 Oct 2009 22:45:53 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Robert Jacques wrote:
On Tue, 20 Oct 2009 20:38:33 -0400, Leandro Lucarella
<llu...@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.
