May 11, 2016
On Wed, May 11, 2016 at 05:55:27PM +0000, deadalnix via Digitalmars-d wrote:
> On Wednesday, 11 May 2016 at 16:44:43 UTC, H. S. Teoh wrote:
> >That's what I've been saying, it should be treated as a special case in the syntax of for-loops, but not as an operator in general.
> >
> 
> Please no special cases.

You misunderstand, what I mean is that the comma should be *part of* for-loop syntax, instead of being part of expression syntax. I.e., for-loop grammar should read something like this:

for-loop:
	"for" "(" loop-init ";" loop-condition ";" loop-increment ")" block

loop-init:
	comma-separated-exprs

loop-condition:
	comma-separated-exprs

loop-increment:
	comma-separated-exprs

comma-separated-exprs:
	expression
	expression "," comma-separated-exprs

And the grammar for expression should have zero references to comma operators.


T

-- 
The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava
May 11, 2016
On Wednesday, 11 May 2016 at 17:15:29 UTC, Kagamin wrote:
> https://dpaste.dzfl.pl/46f24c3def62

It gave compilation error because, one of the parameters of the comma() template in your code is void.  Currently, does D support void as a type of an expression separated by comma?
May 11, 2016
On Wednesday, 11 May 2016 at 18:36:11 UTC, H. S. Teoh wrote:
> On Wed, May 11, 2016 at 05:55:27PM +0000, deadalnix via Digitalmars-d wrote:
>> On Wednesday, 11 May 2016 at 16:44:43 UTC, H. S. Teoh wrote:
>> >That's what I've been saying, it should be treated as a special case in the syntax of for-loops, but not as an operator in general.
>> >
>> 
>> Please no special cases.
>
> You misunderstand, what I mean is that the comma should be *part of* for-loop syntax, instead of being part of expression syntax. I.e., for-loop grammar should read something like this:
>
> for-loop:
> 	"for" "(" loop-init ";" loop-condition ";" loop-increment ")" block
>
> loop-init:
> 	comma-separated-exprs
>
> loop-condition:
> 	comma-separated-exprs
>
> loop-increment:
> 	comma-separated-exprs
>
> comma-separated-exprs:
> 	expression
> 	expression "," comma-separated-exprs
>
> And the grammar for expression should have zero references to comma operators.
>
>
> T

loopinit is a statement, but I see the idea. Works for me.

May 12, 2016
2016-05-12 0:32 GMT+02:00 deadalnix via Digitalmars-d < digitalmars-d@puremagic.com>:

> On Wednesday, 11 May 2016 at 18:36:11 UTC, H. S. Teoh wrote:
>
>> On Wed, May 11, 2016 at 05:55:27PM +0000, deadalnix via Digitalmars-d wrote:
>>
>>> On Wednesday, 11 May 2016 at 16:44:43 UTC, H. S. Teoh wrote:
>>> >That's what I've been saying, it should be treated as a >special case
>>> in the syntax of for-loops, but not as an >operator in general.
>>> >
>>>
>>> Please no special cases.
>>>
>>
>> You misunderstand, what I mean is that the comma should be *part of* for-loop syntax, instead of being part of expression syntax. I.e., for-loop grammar should read something like this:
>>
>> for-loop:
>>         "for" "(" loop-init ";" loop-condition ";" loop-increment ")"
>> block
>>
>> loop-init:
>>         comma-separated-exprs
>>
>> loop-condition:
>>         comma-separated-exprs
>>
>> loop-increment:
>>         comma-separated-exprs
>>
>> comma-separated-exprs:
>>         expression
>>         expression "," comma-separated-exprs
>>
>> And the grammar for expression should have zero references to comma operators.
>>
>>
>> T
>>
>
> loopinit is a statement, but I see the idea. Works for me.
>
>
That is my intent too. However the discussions on the P.R. seem to converge in another direction.


May 12, 2016
On 11/5/2016 21:13, deadalnix wrote:
> On Wednesday, 11 May 2016 at 10:50:47 UTC, Lionello Lunesu wrote:
>> On 10/5/2016 22:16, deadalnix wrote:
>>> On Tuesday, 10 May 2016 at 10:09:40 UTC, Andrei Alexandrescu wrote:
>>>> On 5/10/16 12:52 PM, Mathias Lang wrote:
>>>>> So, following DConf2016, I raised a P.R. to deprecate usage of the
>>>>> comma
>>>>> expressions, except within `for` loops increment [5].
>>>>
>>>> The agreed-upon ideea was to allow uses that don't use the result
>>>> (including for loops). No? -- Andrei
>>>
>>> Let's just make it of void type, there was plan to recycle the syntax
>>> maybe, but whatever we do in the future, this is the sensible first
>>> step.
>>
>> Acutally, we can do two-birds-one-stone: instead of making it void,
>> make it a value tuple!
>>
>
> No. You can't change semantic to something that'll still work under the
> feet of the user. If this syntax is to be recycled to tuple, the value
> needs to be void for a while as to shake out uses.
>
> It is safe to go from void to something else, it isn't not to go from
> something to something else.
>

I agree with you when the 1st something and 2nd something are somehow compatible. void is also a something, but it'd work because it'd never silently change the meaning of code.

I'm trying to think of a case where changing a single value into a tuple with 2 (or more) values would silently change the behavior, but I can't think of any. Seems to me it would always cause an error, iff the result of the comma operator gets used.
May 12, 2016
> int x;
> while( scanf("%d", &x),  x!= 0) // until user input 0.
> {
>    //do something with x
> }
>
> Does anybody think that this is a useful case of comma operator?

I think it's not a safe way to write code. The only time I use comma in C (outside for loops) is when I write some clever macros to do some boilerplate. Comma-operator may have some use in C, but I reckon it makes no sense in D and adds some confusion.

So I join the majority: KILL IT!!

(WITH ACID...)
May 12, 2016
On Wednesday, 11 May 2016 at 18:37:15 UTC, Gopan wrote:
> On Wednesday, 11 May 2016 at 17:15:29 UTC, Kagamin wrote:
>> https://dpaste.dzfl.pl/46f24c3def62
>
> It gave compilation error because, one of the parameters of the comma() template in your code is void.  Currently, does D support void as a type of an expression separated by comma?

Yes, see line 8.
May 12, 2016
Before we get lost in the discussions, let's act on this by disallowing taking the result of the comma operator. Yes there is potential breakage (via typeof as Timon noted) but it's likely to be minimal. Once we have that in place we have more options. Thx! -- Andrei

May 12, 2016
On 5/11/16 7:46 PM, Nick Treleaven wrote:
> In places where the comma operator does help,  use a comma(expr,result)
> template function

Better yet instead of

e1, e2, e3

type

{ e1; e2; return e3; }()


Andrei

May 12, 2016
On 5/11/16 1:10 PM, Kagamin wrote:
> On Wednesday, 11 May 2016 at 16:46:48 UTC, Nick Treleaven wrote:
>> In places where the comma operator does help,  use a
>> comma(expr,result) template function, implemented here:
>> http://forum.dlang.org/post/ngslcl$otg$1@digitalmars.com
>
> May not always work: https://dpaste.dzfl.pl/1ea0df70787b

Yep, that is true. I also found deep in the discussions of previous kill-comma-operator PRs, others have thought of the solution I came up with.

One possible "fix" would be to make all the parameters lazy, and evaluate them all before returning the last :) (Thanks Vladimir for showing us that possibility). But I'm not even going to try and implement that, it's horrific.

-Steve