On 09/23/2012 10:58 PM, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a case even half strong that deprecating the
comma operator could significantly help tuples. Well it essentially
concludes that tuples are mostly fine as they are, and attempts to
embellish them syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so contributions
are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct.
If so, it should be the same as int.
I don't see what's confusing about that.
Those are currently both valid and give the same result:
int.max
(int).max
Anyway, the tuple type should resemble the tuple expression
syntactically.
I also am opposed to the idea to limit
tuples to 2 or more elements. On the contrary, I root for the clean
semantics of having a proper unit type represented as () instead of the
horrible C semantics of the 'void' type. Just make void an alias to ()
for backwards compatibility.
You mean, alias () to 'void' for backwards compatibility. How would
that give 'clean semantics'? It's just syntax. Or is it about void
supporting 'expand'? I don't think that makes sense.
void foo(){}
void main(){
void[] x = new int[42];
foo(x[0].expand); // whut?
}
Also, why the need to special case the for loop? the increment part can
be a regular tuple since the for loop doesn't assign the value of the
expression. for (int i, j; cond; i++, j++) {}
I assume Andrei intends the enclosing parens to be mandatory.
I'd suggest looking at functional implementations such as ML or Haskel[l] for
more inspiration.
They just do the two most obvious things. (well, Haskell has to answer
some questions related to the evaluation model that are irrelevant for
D.)
Neither one has a syntactic construct for building a single element tuple.
Also, I want to add that type declarations should be changed from statements to
expressions so that we could do:
auto tup = (3, "hello");
(int num, string s) = tup; // num == 3, s == "hello"
I'd support the addition of declaration expressions (mainly for using
them in conjuncts of if conditions), but this is not necessary to
enable what you show above.
