On Wednesday, 26 September 2012 at 21:31:13 UTC, Jonathan M Davis
wrote:
On Wednesday, September 26, 2012 21:54:44 foobar wrote:
Library tuples have broken semantics.
Tuples supposed to have _structural_ typing which AFAIK can
only
be correctly implemented in language.
import std.typecons.TypeTuple;
struct MyTuple(T...)() {}
auto libTup = tuple(123, "hello");
MyTuple myTup = libTup; // broken
This is broken cause structs in D are nominally typed and even
though both pack the same inner-types, they are not equal.
Of course, they're not equal. One is a Tuple and one is a
MyTuple. Why on
earth would you expect them to be considered equal? Just use
Tuple. And it's
not like you'd be using MyTuple if tuples were built-in. You'd
just use the
built-in tuples. So, this really makes no sense to me at all.
- Jonathan M Davis
I do _not_ want to consider two different _structs_ (nominal
types) as the same type. I would like to get correct tuple
semantics which means _structural_ typing (I thought I emphasized
that enough in the OP).
A tuple is defined by its contained types, *not* its name.
D is a systems language - there are at least half a dozen posts
on this NG where people implemented their own runtime/standard
libraries for their own purposes. There is at least one OS kernel
project that I know of written in D, also with its own
specialized libs. And of course we should not forget the embedded
hardware space. All provide ample opportunity for exactly the
same scenario as in my example - provide a competing, non
compatible, tuple implementations and voilà, you just got an
incompatibility in the language.
Two ways to prevent this,
1. add support in D in order to allow defining a library tuple
type _with_ _correct_ _structural_ typing.
2. make tuples a language construct.
