On 3/23/14, 7:45 PM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:lgo5ei$1tne$1@digitalmars.com...
>
>> One concession we could make would be to disallow using the result of
>> the operator. That might actually catch all bugs discussed herein.
>>
>> if (condition) ++i, ++j; // fine
>> foreach (e; exp1, exp2) {}   // ERROR
>> if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
>> return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
>>
>> I think this would be a compromise worth looking into.
>>
>
> I could live with that, although I'd still rather see it die.

Boil the frog slowly. -- Andrei

On 3/23/14, 7:50 PM, Adam D. Ruppe wrote:
> On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu wrote:
>> One concession we could make would be to disallow using the result of
>> the operator. That might actually catch all bugs discussed herein.
>
> If we go that far, we might as well just kill the whole thing, since
> half* the reason of using an expression in the first place is to use the
> result.

1. I don't think that's half at all.

2. The fraction we'd disallow contains virtually all bugs that were discussed (in addition of course to legitimate cases)


Andrei

On 3/23/14, 7:50 PM, Adam D. Ruppe wrote:
> int a = something == 1 ? 1
>        : something == 2 ? 2
>        : (assert(0), 0);

That was in Phobos too. Fix:

int a = something == 1 ? 1
       : something == 2 ? 2
       : { assert(0); return 0; }();

There are of course other ways, too, including defining a function that returns its last argument.


Andrei

On 3/23/14, 7:54 PM, Asman01 wrote:
> if(condition) x = 2, y = 3; // fine
> if(condition) f(),x=3; // ERRROR
>
> What do you think?

Too quirky -- Andrei

On 3/23/14, 8:04 PM, Adam D. Ruppe wrote:
> But still, if we make this change at all, I see no reason to keep if(a)
> b, c; given the extreme rarity of that case and the ease with which i
> can be replaced with if(a) { b; c; }

Same misunderstanding all over again. Please understand that breaking code is the worst thing. Arguing that the breakage is easy to fix doesn't help that most important part.

Andrei

Andrei Alexandrescu:

> 2. The fraction we'd disallow contains virtually all bugs that were discussed (in addition of course to legitimate cases)

Including the actual bug found in Phobos? I can't find it now...

Bye,
bearophile

On 3/23/14, 8:12 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> 2. The fraction we'd disallow contains virtually all bugs that were
>> discussed (in addition of course to legitimate cases)
>
> Including the actual bug found in Phobos? I can't find it now...

Yes, can't find it now. It was something like:

foreach (e; chain(iota('a', 'я')), iota('A', 'Я') {
   ...
}

Andrei

On 3/23/14, 8:12 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> 2. The fraction we'd disallow contains virtually all bugs that were
>> discussed (in addition of course to legitimate cases)
>
> Including the actual bug found in Phobos? I can't find it now...

Yes, can't find it now. It was something like:

foreach (e; chain(iota('a', 'я')), iota('A', 'Я')) {
   ...
}

Andrei

On Monday, 24 March 2014 at 03:10:23 UTC, Andrei Alexandrescu wrote:
> On 3/23/14, 7:54 PM, Asman01 wrote:
>> if(condition) x = 2, y = 3; // fine
>> if(condition) f(),x=3; // ERRROR
>>
>> What do you think?
>
> Too quirky -- Andrei

True. I don't want to make a kind of C++

On 2014-03-23 22:31, Andrei Alexandrescu wrote:
> On 3/23/14, 7:21 PM, Kenji Hara wrote:
>> At least I can imagine two reasonable cases.
>>
>> 1. If the code is ported from C/C++, breaking it is not reasonable.
>>
>> 2. If the two expressions are strongly related, using comma operator is
>> reasonable to represent the intensity. I think rather it's an *ability*
>> to represent code meaning by using code style.
>>
>> Kenji Hara
>
> One concession we could make would be to disallow using the result of
> the operator. That might actually catch all bugs discussed herein.
>
> if (condition) ++i, ++j; // fine
> foreach (e; exp1, exp2) {}   // ERROR
> if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
> return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
>
> I think this would be a compromise worth looking into.
>
>
> Andrei
>

How about allowing it only inside parenthesis?

e.g.


if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
if((pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw)) // OK
return (pMgr->RecordEvent(eSE_Weapon), pOwnerRaw); // OK