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

[Steven Schveighoffer]

On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
>> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer  
>> wrote:
>>> Without any research or investigation, what about using a different
>>> set of delimiters for tuples? Like {1,2,3}
>>
>> .... and exactly the syntax I was going to propose!
>
> Assume you had this syntax working today. So instead of writing  
> "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code  
> be better? (Honest question. Don't forget that adding the => syntax for  
> lambda /did/ make for better code.)

I can't honestly say I've used either tuple(a, b, c), or tuples in other  
languages very much.

I can say that I have *avoided* tuples as return values because I don't  
want to type Tuple!(x, y) as the return type.  But I haven't come across  
that need very much.  You can say "yeah, but what about auto?"  Cases I'm  
referring to were to make interface declarations -- can't use auto.

I can similarly say I have never had need to type x, b (i.e. use the  
current comma operator), except in for statements.

I'd be fine with getting rid of comma operator and not doing tuples in the  
language, but it certainly feels weird that we have a tuple type in the  
language, without any formal type unless you alias it (as std.tuple does).

It's almost like instead of saying:

int[] x;

you had to do:

typeof([1,2]) x;

Yeah, with alias, we could arrive at:

Array!int x;

But really, it seems odd that the language has a type for something that  
doesn't have a name/syntax.  Odd, but not unworkable.

I just wanted to point out that it seems the largest trouble,  
implementation-wise, for DIP19 is the choice of parentheses to denote a  
tuple.  If we do want to add built-in tuples, maybe we should be looking  
at a different delimiter.

-Steve