Andrei Alexandrescu wrote: > Timon Gehr wrote: > > > > 1. Deprecate using CommaExpression inside ParanthesizedExpression. (This > > does not > > affect most code that uses the comma operator!) > > 2. Wait a few releases. > > 3. Introduce straightforward, built-in tuples: > [snip] > > We've been thinking of this approach but it would be difficult to pull off.
How would it be difficult to realize? I guess there is literally no serious D code out there that uses anything that could clash with tuple literals. (And if there is any - it can easily be rewritten to use inline delegates instead...) It should also be only a minor change in the grammar. > > One possibility that I hadn't thought before is to use ";" for > separating tuple elements. Upon a casual inspection, it turns out no > statement can be enclosed directly in "(" and ")" so there's no > ambiguity. It would also take care of the issue "did you mean to pass > them as function arguments, or as one tuple argument?" Just a thought... other possibilites: 1. make tuple expansion explicit. //maybe not too great as the built-in TypeTuple expands by default. 2. use the same convention as that used for one-element tuples. void foo(int a,int b,int c); //1 void foo((int,int,int) t,); //2 auto t=(1,2,3); foo(t); //calls 1 (since t is expanded) foo(t,); //calls 2 (t is not expanded) This would change the meaning of trailing "," when tuples are involved though. > > auto t=(1; "string"; 'c'); I have actually considered that too. Some issues: 1. ";" is not as easy to type as "," on many keyboard layouts. (not everybody will use a US Keyboard) 2. It is, like "(|1,2,3|)" another syntax for the same thing that is already present in the language, (template) parameter tuples. Furthermore, Array and AssocArray both use "," as a delimiter, meaning it would add further inconsistency. I think tuple literals should build up on existing features, not be orthogonal to them. imho tuple literals are a logical consequence of generalizing D's design, not an entirely new feature. 3. Most important: Error messages. If ";" is not guaranteed to be a statement delimiter, writing a compiler that can generate meaningful error messages is _much_ more difficult! > > Ehm. > > Andrei Timon