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

[foobar]

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.