DIP19: Remove comma operator from D and provision better syntactic support for tuples
Nick Sabalausky
SeeWebsiteToContactMe at semitwist.com
Sun Sep 23 14:52:30 PDT 2012
Ok, here's a crazy idea:
Do the reasons for explicit tuple-expansion necessarily apply to
zero- and one-element tuples? I'm not so sure. Suppose we allowed
implicit expansion on those...
Now I know what you're thinking: That would be an ugly inconsistency
between tuples of sizes >1 vs <=1. Well, *mechanically* yes, but
consider this:
*Logically* speaking, is there really any difference between a
one-element tuple and an ordinary single value? I don't think so, and
here's why: What is a tuple, logically speaking? Multiple values being
handled as if they were a single value. So what's a one-element tuple?
*One* value being handled as if it were one value - which is *is*.
Similarly, a zero-element tuple is logically equivalent to void (or the
one value a void can have: the value void, a concept which has been
argued in the past that might be useful for D, particularly in
metaprogramming). (I admit this is a little weaker than my argument
for one-element tuples.)
So perhaps zero- and one-element tuples should be implicitly
convertible back and forth with void and ordinary non-tuple values,
respectively (polysemous values?), because that's what they essentially
are.
That means (at least I think it means) that things like () or (1) or
((1)) require no way to disambiguate between tuple and expression,
because either way they're the same thing (or at least freely
convertible).
More information about the Digitalmars-d
mailing list