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

[foobar]

On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky 
wrote:
> 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).

Nope.
One of the ways in math to "build" the positive numbers based on 
set theory is via singletons:
n := |tuple of empty tuples|
so "1" is defined as { {} } whereas "0" is simply {}. That does 
not work with the above suggestion. Now, I realize this is an 
arguably convoluted math example but it does show that the 
treating { {} } as {} is limiting the expressive power of tuples.