On Tuesday, 15 July 2014 at 18:08:15 UTC, Martin Krejcirik wrote:
>>
>> Example?
>>
>
> For loop with multiple variables and various one liners of questionable utility aside:
>
> import std.stdio;
>
> bool funk()
> {
>     static int count;
>     return ++count > 1 ? true : false;
> }
>
> void main()
> {
>     bool flag = false;
>     if (flag && funk)
>         writeln("a");
>     else if (flag=true, flag && funk)
>         writeln("b");
>     else if (flag && funk)
>         writeln("c");
> }

From the previous discussion, everyone agreed that the loop variable usage would not be deprecated, even if the comma operator were deprecated elsewhere. That's pretty much the only place it's really useful. As for those one-liners, "questionable utility" is the keyword (and also "probably buggy").

On Tue, Jul 15, 2014 at 05:26:11PM +0000, Tofu Ninja via Digitalmars-d wrote:
> On Tuesday, 15 July 2014 at 17:09:14 UTC, H. S. Teoh via Digitalmars-d wrote:
> >On Tue, Jul 15, 2014 at 04:52:34PM +0000, Israel Rodriguez via
> >Digitalmars-d wrote:
> >[...]
> >>Nuh uh...The comma operator is too valuable to loose...
> >
> >Please cite an example where it is "valuable"?
> >
> >
> >T
> 
> Yes please, I legitimately can't think of any use case. I don't understand why was this was ever introduced to D? What is the use?

I don't think it was "introduced", probably just inherited from C.

The traditional justification for it in C is to allow writing things like:

	for (i=0, j=0; i < 10 && j < 20; i++, j+=2) {
		...
	}

However, this can be easily implemented as special syntax for for-loops; it needn't be a general syntax that can be used everywhere.

There are some other marginal use cases where it saves a tiny bit of typing, but really, in this day and age, the only time that's really *needed* is when submitting entries to the IOCCC. :-P

Of course, then C++ came along and made the whole thing a whole order of magnitude worse, by introducing operator,(), which leads to nastiness like:

	void func(Array<2,int> matrix) {
		matrix = 1, 2, 3,
			 4, 5, 6,
			 7, 8, 9;
	}

which looks cool until you think about it some more, and then you realize that there are just so many ways in which this can go really, horribly wrong.

Personally, I can't wait for the comma operator to be killed off for good. Preferably with extreme prejudice.


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz

On 07/15/2014 11:08 AM, Martin Krejcirik wrote:
>>
>> Example?
>>
>
> For loop with multiple variables and various one liners of questionable
> utility aside:
>
> import std.stdio;
>
> bool funk()
> {
>      static int count;
>      return ++count > 1 ? true : false;
> }
>
> void main()
> {
>      bool flag = false;
>      if (flag && funk)
>          writeln("a");
>      else if (flag=true, flag && funk)
>          writeln("b");
>      else if (flag && funk)
>          writeln("c");
> }
>

Is the following the intended equivalent?

    if (flag && funk)
        writeln("a");
    else {
        flag=true;

        if (flag && funk)
            writeln("b");
        else if (flag && funk)
            writeln("c");
    }

If I had to ask nobody should use the version you wrote! ;)

Ali

On Tuesday, 15 July 2014 at 18:08:15 UTC, Martin Krejcirik wrote:
>>
>> Example?
>>
>
> For loop with multiple variables and various one liners of questionable utility aside:
>
> import std.stdio;
>
> bool funk()
> {
>     static int count;
>     return ++count > 1 ? true : false;
> }
>
> void main()
> {
>     bool flag = false;
>     if (flag && funk)
>         writeln("a");
>     else if (flag=true, flag && funk)
>         writeln("b");
>     else if (flag && funk)
>         writeln("c");
> }

cute, but I'd still prefer this

void main()
{
    bool flag = false;
    if (flag && funk)
        writeln("a");
    else
    {
        flag = true;
        if (flag && funk)
            writeln("b");
        else if (flag && funk)
            writeln("c");
    }
}

and not just because I don't like the comma. I'd say it's generally bad practice to hide that write to `flag` inside the if condition. By spreading it out it is clear that the different conditions are evaluated with different external state.

The comma operators entire job is to inject state changes where the reader doesn't expect them. It's a misfeature of C that we've sadly inherited and should rid ourselves from.

On Tuesday, 15 July 2014 at 18:50:08 UTC, John Colvin wrote:
> The comma operators entire job is to inject state changes where the reader doesn't expect them. It's a misfeature of C that we've sadly inherited and should rid ourselves from.

http://forum.dlang.org/thread/xmqzrgysgxdmqrnfpxdq@forum.dlang.org

The comma operator will be harder to fix than this bug in the exception handling grammar, and I couldn't even get that approved.

On Tuesday, 15 July 2014 at 18:50:08 UTC, John Colvin wrote:
> and not just because I don't like the comma. I'd say it's generally bad practice to hide that write to `flag` inside the

You are right for the 'final' code, but the point of my example is, that I can move the flag to another if and don't have to change anything else.

Also an assignment is not allowed in a condition and without the comma operator, it wouldn't be possible at all. That's way too restrictive.

Martin Krejcirik:

> Also an assignment is not allowed in a condition and without the comma operator, it wouldn't be possible at all. That's way too restrictive.

If I find code like yours, I refactor it ASAP :-)

Bye,
bearophile

On Tue, Jul 15, 2014 at 07:16:17PM +0000, Martin Krejcirik via Digitalmars-d wrote:
> On Tuesday, 15 July 2014 at 18:50:08 UTC, John Colvin wrote:
> >and not just because I don't like the comma. I'd say it's generally bad practice to hide that write to `flag` inside the
> 
> You are right for the 'final' code, but the point of my example is, that I can move the flag to another if and don't have to change anything else.
> 
> Also an assignment is not allowed in a condition and without the comma operator, it wouldn't be possible at all. That's way too restrictive.

Not true:

	T* ptr;
	if ((ptr = getPtr()) !is null) {
		...
	}

Nevertheless, it's a bad idea to have side effects in if-conditions. It makes code hard to follow, and is a cosy place for subtle bugs to hide.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

On Tue, Jul 15, 2014 at 12:46:04PM -0700, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jul 15, 2014 at 07:16:17PM +0000, Martin Krejcirik via Digitalmars-d wrote:
> > On Tuesday, 15 July 2014 at 18:50:08 UTC, John Colvin wrote:
> > >and not just because I don't like the comma. I'd say it's generally bad practice to hide that write to `flag` inside the
> > 
> > You are right for the 'final' code, but the point of my example is, that I can move the flag to another if and don't have to change anything else.
> > 
> > Also an assignment is not allowed in a condition and without the comma operator, it wouldn't be possible at all. That's way too restrictive.
> 
> Not true:
> 
> 	T* ptr;
> 	if ((ptr = getPtr()) !is null) {
> 		...
> 	}
[...]

Better yet, this syntax is supported:

	if (auto ptr = getPtr())
	{
		// ptr is not null here
	}


T

-- 
Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds

On Tuesday, 15 July 2014 at 17:26:12 UTC, Tofu Ninja wrote:
> On Tuesday, 15 July 2014 at 17:09:14 UTC, H. S. Teoh via Digitalmars-d wrote:
>> On Tue, Jul 15, 2014 at 04:52:34PM +0000, Israel Rodriguez via Digitalmars-d wrote:
>> [...]
>>> Nuh uh...The comma operator is too valuable to loose...
>>
>> Please cite an example where it is "valuable"?
>>
>>
>> T
>
> Yes please, I legitimately can't think of any use case. I don't understand why was this was ever introduced to D? What is the use?

It appears Microsoft is musing the idea of adding this operator to C# and VB.Net.  Only instead of it being a comma, they're going with a semicolon.
https://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation

I dislike the comma operator as well, but would there be any problems if it were a semicolon instead?  I think the new symbol would fit well in for() loops.