On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
