Should the comma operator be removed in D2?

KennyTM~ kennytm at gmail.com
Tue Nov 17 15:51:58 PST 2009


On Nov 18, 09 07:25, Ellery Newcomer wrote:
> Bill Baxter wrote:
>> On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer
>> <ellery-newcomer at utulsa.edu>  wrote:
>>> Bill Baxter wrote:
>>>> On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~<kennytm at gmail.com>  wrote:
>>>>> On Nov 18, 09 05:40, Ellery Newcomer wrote:
>>>>>> Bill Baxter wrote:
>>>>>>> However, I think for the good of humanity we can accept that one
>>>>>>> little bizarre example of legal C syntax not doing the same thing in
>>>>>>> D.
>>>>>> int[] i;
>>>>>>
>>>>>> auto a = (i)[0];
>>>>>>
>>>>>> what does this do?
>>>>> (i) should not construct a tuple. Probably (i,).
>>>> That's Python's solution and it seems to work out ok.
>>>>
>>>> --bb
>>> How do we express tuple types? ...
>>> These won't work:
>>> ...
>>> (int,int) [] lst; //want
>>
>> Why won't that work?  You may be right, but that particular
>> declaration doesn't seem ambiguous to me.
>>
>> --bb
>
> foo!( (i,i) ) ();
>
> compiler doesn't know if 'i' is a type or a variable.
> Like I said, the problem already exists for eg
>
> foo!( i ) ();
>
> and isn't semantically ambiguous (as far as I know..), so it is doable.
>
> at statement level, it would require a lot of lookahead to distinguish eg
>
> (i,i)[0] = blah;
> (i,i)[0] blah;
>
> Not my idea of good language design (one character deep in the
> production - can you say fortran :) actually fortran is worse, it
> discards whitespace as token separators)

int[2][2][2][2][2][2][2][2][2][2] a;
alias int b;

a[1][1][1][1][1][1][1][1][1][1] = c;
b[1][1][1][1][1][1][1][1][1][1] d;

still a lot of look ahead :p



More information about the Digitalmars-d mailing list