Tuple literal syntax

[Andrei Alexandrescu]

On 10/7/10 1:04 CDT, Walter Bright wrote:
> There have been a couple of looong threads about tuples:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html
>
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html
>
>
> A lot of it foundered on what the syntax for tuple literals should be.
> The top of the list is simply enclosing them in ( ). The problem with
> this is
>
> (expression)
>
> Is that a parenthesized expression, or a tuple? This really matters,
> since (e)[0] means very different things for the two. Finally, I got to
> thinking, why not just make it a special case:
>
>
> ( ) == tuple
> (a) == parenthesized expression
> (a,b) == tuple
> (a,b,c) == tuple
> (a,b,c,d) == tuple
>
> etc.
>
> No ambiguities! Only one special case. I submit this special case is
> rare, because who wants to define a function that returns a tuple of 1?
> Such will come about from generative programming, but:
>
> (a,b,c)[0]
>
> may be how the generative programming works, and that suggests:
>
> (a,0)[0]
>
> as how a user could generate a tuple of 1. Awkward, sure, but like I
> said, I think this would be rare.

Sorry for being Debbie Downer in this thread, but I'm not seeing a lot 
of progress here. This is nothing but a syntax cutesy that helps 
Tuple!(A, B) and tuple(a, b) and leaves all other issues related to 
tuples unresolved (I'm actually afraid that it exacerbates them).

One good thing about Tuple is that it allows names of fields, so 
functions can return tuples with conveniently named fields, e.g. 
Tuple!(bool, "found", size_t, "position") etc. without having to define 
little structs everywhere and fostering simple, clear code on the caller 
side.

Also, obviously, empty tuples and tuples with one element are 
self-explanatory (Tuple!() and Tuple!(int) for types, tuple() and 
tuple(4) for values).

Up until recently the syntax t[i] didn't work for tuples, forcing 
t.field[i]. This marginally improves usage of tuples. There are still 
other issues left due to compiler bugs; for example slicing t[a .. b] is 
supposed to work but it doesn't. But my question is, do we need more 
notation, more special cases, more ambiguities, more solution to 
ambiguities, more corner cases (there's already a request for handling 
void in a particular way)...? And for what? Quite literally because we 
refuse to call a tuple a tuple? I'm not seeing much gain here. Syntactic 
sugar is good in moderate quantities, but in Perlis' words this is bound 
to cause cancer of the semicolon.

My suggestion on improving tuples is to fix the compiler bugs that 
currently hamstrung Tuple and to make it the best it can be. Once we're 
clear on the functionality, it would be great to see how we can package 
it better with a bit of language support.


Andrei