On Sun, Apr 29, 2012 at 11:55:43PM -0700, Jonathan M Davis wrote: [...]
> Honestly, I don't think that you _can_ take much from this thread other than the fact that pretty _every_ feature is wanted and used by someone, even if other people hate it. Pretty much every feature listed as undesirable by someone was listed as desirable by someone else.
[...]

So far, I've not seen a single response in favor of keeping the comma operator.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.

On Mon, Apr 30, 2012 at 05:26:15PM +0200, Alex Rønne Petersen wrote:
> On 30-04-2012 01:41, bearophile wrote:
> >Walter:
> >
> >>What's your list?
> >
> >This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei?
[...]
> I think the one thing there is universal agreement on is that the comma operator has to go.
[...]

+1. Let's rid the comma operator of its miserable existence.


T

-- 
Computers aren't intelligent; they only think they are.

On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
> So far, I've not seen a single response in favor of keeping the comma operator.

I kinda like having it....

On Mon, 30 Apr 2012 17:35:14 +0200, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Mon, Apr 30, 2012 at 10:21:23AM +0200, bearophile wrote:
>> H. S. Teoh:
>>
>> >I think the correct solution here is to use alias. (If that doesn't
>> >work, then it should be made to work. It's a lot cleaner and doesn't
>> >introduce potentially nasty ambiguities into code,
>>
>> What ambiguities?
> [...]
>
> When you have nested with's.
>
> Or when the object members shadow local variables in the parent scope.
>
> 	struct S {
> 		int x;
> 	}
>
> 	void main() {
> 		int x, y;
> 		S s;
>
> 		with(s) {
> 			x = 1;
> 			y = 2;
> 		}
> 	}
>
> Technically it's unambiguous which symbols are being referred to, but it
> makes the code hard to read because casual scanning will usually get it
> wrong. Plus, you're entirely at the mercy of the definition of S. If
> it's an imported object from an external library, for example, then when
> upstream makes changes to their struct/class there's a risk of
> introducing subtle errors into existing, correct code (by suddenly
> interpreting an identifier differently). This is never good.
>
> It gets worse with nested with's: when any object being with'd changes,
> you risk identifier collision. The worst thing is that this can happen
> just by upstream(s) changing object definitions, with no change in user
> code.
>
>
> T
>

I think struct literals is worse in this regard:
struct S {
  int a;
  int b;
}

user code:
S(1, 2);

The author of S cleans up the struct and changes the order:
struct S {
  int b;
  int a;
}

Suddely user code has bugs. I believe the reason named parameters hasn't been introduced is because the names becomes part of the public interface. Well.. With struct literals, the _position_ of the parameters is part of the interface.

H. S. Teoh:

> When you have nested with's.
>
> Or when the object members shadow local variables in the parent scope.
>
> 	struct S {
> 		int x;
> 	}
>
> 	void main() {
> 		int x, y;
> 		S s;
>
> 		with(s) {
> 			x = 1;
> 			y = 2;
> 		}
> 	}

That code doesn't compile:

test.d(10): Error: with symbol test.S.x is shadowing local symbol
test.main.x

Bye,
bearophile

On Monday, 30 April 2012 at 15:38:32 UTC, Adam D. Ruppe wrote:
> On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
>> So far, I've not seen a single response in favor of keeping the comma operator.
>
> I kinda like having it....

I too and I am afraid that disallowing it would result that something would be broken.

On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
> So far, I've not seen a single response in favor of keeping the comma
> operator.

Very few want it, but as a practicality, it would be unwise to remove it (would break an awful lot of code).

On Monday, 30 April 2012 at 15:19:29 UTC, Alex Rønne Petersen wrote:
> On 30-04-2012 11:46, SomeDude wrote:
>
> I don't have a clone of my repo from where I am now, so I can't count, but it usually takes around ~30 seconds with DMD, ~2 minutes with GDC.

For how many files/lines of code ?

On Monday, 30 April 2012 at 16:14:58 UTC, SomeDude wrote:
> On Monday, 30 April 2012 at 15:19:29 UTC, Alex Rønne Petersen wrote:
>> On 30-04-2012 11:46, SomeDude wrote:
>>
>> I don't have a clone of my repo from where I am now, so I can't count, but it usually takes around ~30 seconds with DMD, ~2 minutes with GDC.
>
> For how many files/lines of code ?

And on what hardware ? I'd like to have a bit of an idea of how
fast the compilers really are.

Le 30/04/2012 18:13, Peter Alexander a écrit :
> On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
>> So far, I've not seen a single response in favor of keeping the comma
>> operator.
>
> Very few want it, but as a practicality, it would be unwise to remove it
> (would break an awful lot of code).
>

Some have proposed that comma operator could create tuples. If void members in tuples are automagically skipped, this won't break that many code.

A first step in that direction would be to deprecate comma expression where expressions before the last one have not type void.