Tuple literal syntax

[retard]

Thu, 07 Oct 2010 14:11:21 -0500, Andrei Alexandrescu wrote:

> On 10/7/10 13:56 CDT, 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.
> 
> Yah, and it might be the case that we're too close to the matter
> sometimes. A simple out-of-the-box list should help. I'd start it like
> this:
> 
> - must contain an unlimited number of values, including non-distinct
> types etc.
> 
> - should be first-class values (e.g. array of tuples or returning tuples
> should require no tricks)
> 
> - should support controlled expansion, i.e. I decide when the tuple
> "explodes" whereas everywhere else it's a sheer value. Consider:
> 
> void foo(T)(T obj);
> void foo(T, U)(T obj1, U obj2);
> foo(tuple(1, 2.2));
> 
> Which function should be called? Any way we go, we should be able to
> call the first overload (because tuples are first-class values!!! the
> circle closes!!!)  but we should also be able to call the second
> overload if we so want. (By sheer luck, Tuple currently supports that
> beautifully: foo(tuple(1, 2.2)) calls the first overload and
> foo(tuple(1, 2.2).expand) calls the second one.)
> 
> - should support coherent conversion and perhaps subtyping, taking
> projections (slices), cross-product (concatenation)
> 
> - should be easy to use, terse, and self-explanatory
> 
> - should support simple "gathering" (assigning from various values) and
> "scattering" (assigning to various values)
> 
> What else?

Looks really good IMO.

The same .expand (or some other "method") should probably also work when 
dealing with tuples of types. I didn't look how it works now. The auto-
flattening isn't always desirable. I guess the other places of confusion 
are interaction with built-in statements and other features, e.g.

auto foo = (1,2,3);

auto bar = [foo];

Should there be some way to construct a [1,2,3] array from the tuple or 
should the only be a way to construct arrays of the type tuple!(int)[] or 
something similar. The auto-flattening could be used in quite many places 
(as cases in switches etc.)