DIP19: Remove comma operator from D and provision better syntactic support for tuples

Jonathan M Davis jmdavisProg at gmx.com
Wed Sep 26 15:16:18 PDT 2012


On Thursday, September 27, 2012 00:05:41 bearophile wrote:
> Jonathan M Davis:
> > So, this really makes no sense to me at all.
> 
> I agree that foobar examples aren't so good. But it's true that
> Tuple() gives some troubles regarding missed structural typing:
> 
> 
> import std.stdio, std.typecons;
> alias Tuple!(float, float) T1;
> alias Tuple!(float,"x", float,"y") T2;
> void foo1(T1 t) {}
> void foo2(T2 t) {}
> void main() {
> auto p1 = T1(1, 2);
> auto p2 = T2(1, 2);
> p1 = p2; // no error
> p2 = p1; // no error
> T1[] a1;
> T2[] a2;
> a1 = a2; // error
> a2 = a1; // error
> foo1(p2); // error
> foo2(p1); // error
> }
> 
> 
> Generally I think "p1 = p2;" is OK, while "p2 = p1;" is not so
> good, because T2 is more specialized.
> 
> There are several other more or less similar things related to
> structural typing of tuples that a well implemented built-in
> tuple type will need to address. In Bugzilla there are some open
> bug reports on similar matters. Fixing them with the library
> defined tuples is hard. Of course a possible solution is to
> improve the D language to allow the programmer to specify very
> good struct-based tuples in library code, I think but doing this
> is more complex than implementing good built-in tuples.

It sounds to me like the reason that structural typing is needed is because 
Tuple allows you to name its fields, which I've always thought was a bad idea, 
and which a built-in tuple definitely wouldn't do. If you couldn't name its 
fields, then any Tuple containing the same sequence of types would be the same 
type. So, the problem is caused by a feature that built-in tuples wouldn't 
even have.

- Jonathan M Davis


More information about the Digitalmars-d mailing list