On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic wrote:
> On 3/26/14, Kagamin <spam@here.lot> wrote:
>> On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
>>> I think total removal of the comma operator could offer more
>>> readable D code.
>>
>> No, complete removal will make code less readable. Why can't you
>> read commas?
>
> Have you never experienced this bug before?
>
> enum vals = [
>     "afoo01foo01",
>     "bbar02foo02",
>     "cdoo03foo03",
>     "dfoo01foo04",
>     "ebar02foo01",
>     "fdoo03foo02",
>     "gfoo01foo03",
>     "hbar02foo04",
>     "aidoo03foo01"
>     "jfoo01foo02a",
>     "kbar02foo03",
>     "ldoo03foo04",
> ];
>
> This has nothing to do with the comma operator, but what it has to do
> is with readability. The comma is easily misplaced.

I experienced it this very morning, testing your getopt code :/

Forgot to place the parens at all :
string[] args = ["myProgram.exe" "--users" "foo" "bar"];

I know the code is wrong, but there's something that seriously pisses me off about code that compiles anyways, then does weird stuff.

Implicit string concatenation brings *no* "functional" gains, but *is* a source of bugs. That should also killed with extreme prejudice.

On Tuesday, 25 March 2014 at 19:25:43 UTC, ixid wrote:
>> I think this should not be done. Note that even though code which is D could reintroduce commas safely, C code will still exist at that time, and likely need porting to D. The principle that C code should either do the same thing, or not compile, would be violated.
>
> What would be an example of C code that would compile in a D
> where the comma operator was used for tuples? Also why is cut and
> pasting C code to D so important? If it's non-trivial surely
> people will just use extern C. If it's trivial they can make the
> minor improvements necessary.

This is valid in both C and C++:

  i, j = 0, 1;

It is equivalent to the following:

  i;
  j = 0;
  1;

There might be more complex examples in C++ however, which allows more complex L-value expressions. This is invalid C, but valid C++:

  (i, j) = (0, 1);

In C++, it is equivalent to:

  j = 1;

On Wednesday, 26 March 2014 at 10:54:44 UTC, bearophile wrote:
> When I read code quickly I sometimes mistake what's the what part of the expression returned.

With this proposal an attempt to return the result of the comma operator won't compile.

On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic wrote:
> Have you never experienced this bug before?
>
> enum vals = [
>     "afoo01foo01",
>     "bbar02foo02",
>     "cdoo03foo03",
>     "dfoo01foo04",
>     "ebar02foo01",
>     "fdoo03foo02",
>     "gfoo01foo03",
>     "hbar02foo04",
>     "aidoo03foo01"
>     "jfoo01foo02a",
>     "kbar02foo03",
>     "ldoo03foo04",
> ];

In such case I add lines by copying other lines, so there's little chance to miss a comma. Well, I don't think you can find someone, who would defend implicit concatenation.

On Wed, 26 Mar 2014 10:24:59 -0400, Kagamin <spam@here.lot> wrote:

> On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic wrote:
>> Have you never experienced this bug before?
>>
>> enum vals = [
>>     "afoo01foo01",
>>     "bbar02foo02",
>>     "cdoo03foo03",
>>     "dfoo01foo04",
>>     "ebar02foo01",
>>     "fdoo03foo02",
>>     "gfoo01foo03",
>>     "hbar02foo04",
>>     "aidoo03foo01"
>>     "jfoo01foo02a",
>>     "kbar02foo03",
>>     "ldoo03foo04",
>> ];
>
> In such case I add lines by copying other lines, so there's little chance to miss a comma. Well, I don't think you can find someone, who would defend implicit concatenation.

Frequently, I have situations where I do not put a comma on the last element. Then via cut and paste, it is moved up without adding a comma, or you add more elements without adding the comma.

Considering we have a concatenation operator, with constant folding, and we don't have the c preprocessor to deal with, we should kill this with fire.

-Steve

On Wednesday, 26 March 2014 at 14:39:11 UTC, Steven Schveighoffer wrote:
> Frequently, I have situations where I do not put a comma on the last element.

Hehe, I don't use features which I can't afford (e.g. template black magic). Otherwise I won't be able to handle my own code.

On Wed, Mar 26, 2014 at 08:24:23AM +0000, Kagamin wrote:
> On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
> >I think total removal of the comma operator could offer more readable D code.
> 
> No, complete removal will make code less readable. Why can't you read commas?

Are you talking about the comma *operator*, or are you talking about commas in general? Please don't confuse the two.

OTOH, the fact that people don't even understand what the comma operator is, is a good reason to kill it. With extreme prejudice. And for the sake of those who aren't clear: the comma operator has NOTHING to do with the following:

	int x,y;
	int[] a = [1,2,3];
	func(a,x,y);
	enum E { A, B, C }

So relax. We're not proposing to get rid of the comma in the whole language. What we're proposing is to get rid of things like this:

	int x = 1, 5;	// hands up, how many understand what this does?


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

On 3/26/14, 7:39 AM, Steven Schveighoffer wrote:
> On Wed, 26 Mar 2014 10:24:59 -0400, Kagamin <spam@here.lot> wrote:
>
>> On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic wrote:
>>> Have you never experienced this bug before?
>>>
>>> enum vals = [
>>>     "afoo01foo01",
>>>     "bbar02foo02",
>>>     "cdoo03foo03",
>>>     "dfoo01foo04",
>>>     "ebar02foo01",
>>>     "fdoo03foo02",
>>>     "gfoo01foo03",
>>>     "hbar02foo04",
>>>     "aidoo03foo01"
>>>     "jfoo01foo02a",
>>>     "kbar02foo03",
>>>     "ldoo03foo04",
>>> ];
>>
>> In such case I add lines by copying other lines, so there's little
>> chance to miss a comma. Well, I don't think you can find someone, who
>> would defend implicit concatenation.
>
> Frequently, I have situations where I do not put a comma on the last
> element.

Big mistake :o). -- Andrei

On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei Alexandrescu wrote:
> Big mistake :o). -- Andrei

Yeah, how are we doing on that front? Have any decisions actually been made?

On 3/26/14, 10:34 AM, monarch_dodra wrote:
> On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei Alexandrescu wrote:
>> Big mistake :o). -- Andrei
>
> Yeah, how are we doing on that front? Have any decisions actually been
> made?

What front?