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