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

[Andrei Alexandrescu]

On 9/24/12 1:01 AM, Nick Sabalausky wrote:
> On Sun, 23 Sep 2012 18:48:22 -0400
> Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org>  wrote:
>>
>> Once a one-element tuple becomes equivalent to the actual item,
>> there's an explosion of trouble and special cases in the language and
>> in code that uses it. For example, divide and conquer code that
>> manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would
>> suddenly get to cases in which the slices are no longer tuples, and
>> so on. And that's only the beginning.
>>
>
> I think one of us is missing something, and I'm not entirely sure
> who.
>
> As I explained (perhaps poorly), the zero- and one-element tuples *would
> still be* tuples. They would just be implicitly convertible to
> non-tuple form *if* needed, and vice versa. Do you see a reason why
> that would *necessarily* not be the case?

It just creates endless little problems and confusion coming outta the 
woodwork, as others have pointed out in response to this. There are 
languages that have also explored a similar approach - a value can be 
automatically converted to a one-element array and vice versa. It's 
problematic, especially in a language with generics and function 
overloading.

>> I think it's safe to just not even discuss it.
>
> A nice way to put it :/  Part politician perhaps? ;)

I meant it in a simple and forward way - all I want is to save time and 
trouble in exploring a no-win design. From sheer experience gathered 
from years at hacking at this stuff I know this can be done but is not 
worth the trouble. Since it can be done, there's no argument that would 
definitively close the discussion, and that demotivates me from coming 
up with explanations.


Andrei