Tuple literal syntax

[retard]

Thu, 07 Oct 2010 18:56:46 +0000, retard wrote:

> Thu, 07 Oct 2010 13:48:31 -0500, Andrei Alexandrescu wrote:
> 
>> On 10/7/10 13:44 CDT, retard wrote:
>>> Thu, 07 Oct 2010 19:12:45 +0200, Simen kjaeraas wrote:
>>>
>>>> retard<re at tard.com.invalid>  wrote:
>>>>
>>>>> If you don't have first class tuple constructors and define them
>>>>> with a template, that's unfortunately not structural typing.
>>>>
>>>> Might I inquire as to why?
>>>
>>> I see these "tuples" defined with a template merely as structs in
>>> disguise. They don't cover all the cases where built-in first class
>>> tuples can be used.
>> 
>> Could you please take the time to put together a list of requirements?
>> That would be great for either making Tuple better or for improving the
>> language.
> 
> Sure, but I can't really promise to have to capacity to think about
> every possible case when we are discussing D. There are so many complex
> features! I think a more or less complete list can already be
> constructed from all past discussions here. The tuple issues come up
> every now and then.
> 
> FWIW, the library provided solution with syntactical support doesn't
> sound so bad now that I think about it. We just need to know, what we
> are trying to solve here. The bigger problems come up when overloading
> the same system with mixed value/type/alias tuples.

If I think about some basic features in other tuple using languages, you 
need to have a way to

1) construct tuples (as a statement and as an expression)

auto foo = (1,2);
return (1,2);

foo = { return (0, 42); }();

2) interact nicely with built-in types (AAs, structs, classes, arrays, 
nested tuples, and recursively all permutations of these come to mind)

3) extract a single field

auto foo = (1,2);
auto bar = foo._1;  // or foo[0]

4) extract all fields ("pattern matching")

auto baz = (1,2);
auto (foo, bar) = baz;

auto (foo2, _) = baz; // maybe even this? not necessary

5) tuples with named fields (beware conflicts with other literals)

auto baz = (foo: 1, bar: 2);

auto buz = baz.foo; // like this maybe?

6) since they use structural typing semantics, this should work

auto foo = (1,2);
auto bar = (2,3);

bar = foo;

---

I can't decide how the tuples should work with e.g. parameter lists. I'm 
not a big friend of auto-flattening on any level. E.g.

void foo((int,int) bar);

and

void foo(int a, int b);

should have a different type signature IMO.

These rules should cleanly generalize to mixed tuples in type context, 
when used in metaprogramming (e.g. parametric types).

People probably want to construct other literals such as arrays from 
tuples. These are all special cases from type system's pov. I have no 
opinion. Well I have -- I don't like messy rules.