March 24, 2014
On Sun, 23 Mar 2014 20:56:25 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

Would it have any effect on:

int *p, q;

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
March 24, 2014
On Monday, 24 March 2014 at 10:57:45 UTC, Regan Heath wrote:
> On Sun, 23 Mar 2014 20:56:25 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>
> Would it have any effect on:
>
> int *p, q;

That's not a comma operator. So no. BTW, I'd *STRONGLY* urge you to write that as:
int* p, q;

since in D, both "p" and "q" are of type "int*", unlike in C.
March 24, 2014
On Monday, 24 March 2014 at 01:28:02 UTC, Kenji Hara wrote:
> I'm partially against to it.
>
> 1. I think removing comma operator does not have useful effect for tuple
> syntax discussion. For example:
>
>    1a. If you want to use parenthesis syntax (...) for tuple, we should
> resolve one-element tuple ambiguity first.
>          (exp)   // one-element tuple, or just an expression ?
>       And,  removing comma operator does not resolve this issue.

I believe this is a non-issue. From a language-users POV, there should be no difference between a one-element tuple and an expression, thus there's no need to distinguish the two. (The actual implementation in the compiler may of course treat them differently.)

>
>    1b. If you choose other syntax for tuple, comma operator will be no
> longer related to tuple syntax discussion.
>         {exp, exp2}  // eg. using brace for tuple syntax no longer touch to
> comma operator
>

I'd prefer parentheses, but that's bike-shedding, of course. In any case, it's better to have some freedom in choosing the final syntax, rather than being forced to use one that is less well-liked/intuitive.

> 2. Indeed in some case comma operator is bug-prone, but if it is used
> directly on the ExpStatement, it's still useful to me.
>
>     foreach (e; exp1, exp2) {}   // maybe bug?
>     if (cond) exp1, exp2;   // in most case, this is not a bug.
>
>    So, completely removing comma operator will cause negative affect in
> some cases.

IMO this is bad style. It only saves a few characters, but hampers readability. The example with the assert() and the ternary operator that someone else gave is much more relevant, however, as it's somewhat harder to rewrite (need to resort to a lambda literal, or rewrite as statements).
March 24, 2014
On Monday, 24 March 2014 at 04:00:14 UTC, Andrei Alexandrescu wrote:
> On 3/23/14, 8:30 PM, bearophile wrote:
>> How is this more limited change affecting possible future syntax usage
>> of commas for tuples? :-)
>
> The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei

This is nice, although I guess it will make parsing harder. It probably means that the distinction between "," as operator and tuple element separator will be context-dependent.
March 24, 2014
On Monday, 24 March 2014 at 12:10:40 UTC, Marc Schütz wrote:
> On Monday, 24 March 2014 at 01:28:02 UTC, Kenji Hara wrote:
>> I'm partially against to it.
>>
>> 1. I think removing comma operator does not have useful effect for tuple
>> syntax discussion. For example:
>>
>>   1a. If you want to use parenthesis syntax (...) for tuple, we should
>> resolve one-element tuple ambiguity first.
>>         (exp)   // one-element tuple, or just an expression ?
>>      And,  removing comma operator does not resolve this issue.
>
> I believe this is a non-issue. From a language-users POV, there should be no difference between a one-element tuple and an expression, thus there's no need to distinguish the two. (The actual implementation in the compiler may of course treat them differently.)

Or, if you really want to distinguish them, this would work:

(1,2)    two-element tuple
(1,)     one-element tuple
(1)      simple expression
(,)      empty tuple
March 24, 2014
On Monday, 24 March 2014 at 04:04:55 UTC, Andrei Alexandrescu
wrote:
> On 3/23/14, 8:22 PM, Etienne Cimon wrote:
>> How about allowing it only inside parenthesis?
>
> That works but breaks more valid code. -- Andrei

I don't think so. Tuple literal syntax would presumably use
parenthesis:

int i;
float j;
(i, j) = func_returning_tuple();
auto (a,b,c) = another_func();
(x, y) = (y, x);

Keeping the operator inside parentheses would therefore kill
these options.
March 24, 2014
Please kill the comma operator with fire. Is is just bad.

On Monday, 24 March 2014 at 12:20:11 UTC, Marc Schütz wrote:
> Or, if you really want to distinguish them, this would work:
>
> (1,2)    two-element tuple
> (1,)     one-element tuple
> (1)      simple expression
> (,)      empty tuple

I am a regular Python user, and I advise against using this syntax for tuples. I have been bitten many times by something which I thought was a tuple becoming an expression and something I thought was a simple expression becoming a tuple. It may be less of an issue in a static language, but it will still be an issue. I don't have an alternative syntax to propose.
March 24, 2014
On Monday, 24 March 2014 at 02:26:12 UTC, deadalnix wrote:
> On Monday, 24 March 2014 at 01:36:46 UTC, bearophile wrote:
>> C code should not silently behave differently in D, even five years from now, so I am not interested in using the C comma syntax for D tuples. I am OK with a D tuple syntax that is not allowed in C.
>>
>
> It won't silently break. I concede it will break.

There are some corner cases where it might silently behave differently:

int a, b;
a, b = (1, 2);

This is apparently allowed in C, and will be equivalent to "b = 2;". But if we require parentheses, at least GCC 4.8.1 rejects it:

int a, b;
(a, b) = (1, 2);

tuple.c:3:8: error: lvalue required as left operand of assignment
 (a, b) = (1, 2);
        ^

So, with carefully tweaking the tuple syntax, we can probably reject any valid C code.
March 24, 2014
On Mon, 2014-03-24 at 12:20 +0000, Marc =?UTF-8?B?U2Now7x0eiI=?=
@puremagic.com wrote:
[…]
> Or, if you really want to distinguish them, this would work:
> 
> (1,2)    two-element tuple
> (1,)     one-element tuple
> (1)      simple expression
> (,)      empty tuple

The Python solution is:

(1, 2)  two-element tuple
(1,)  one-element tuple
(1)  simple expression
()  empty tuple
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

March 24, 2014
On Sun, 23 Mar 2014 22:31:25 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.

In fact, if this was the case, I would use the comma operator more. How many times I have to change:

if(cond)
   exp;

into

if(cond)
{
   exp;
   exp2;
}

Would be nice to just do:

if(cond)
   exp, exp2;

-Steve