www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should we deprecate comma?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

Andrei
Mar 23 2014
next sibling parent reply "Asman01" <jckj33 gmail.com> writes:
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


Then things like this c = f(),b*c; became invalid? if so, yes. I 
did a lot of C and never found this useful just unlike.
Mar 23 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 23.03.2014 22:08, schrieb Asman01:

 On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


 Then things like this c = f(),b*c; became invalid? if so, yes. I did a
 lot of C and never found this useful just unlike.


Interesting interview questions. :)
Mar 23 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


Yes please. This has been discussed to death several time.
Mar 23 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


Yes, kill it please.
Mar 23 2014
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


Kill it. Eventually we may be able to reclaim it as something 
more useful.
Mar 23 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 23 March 2014 at 22:03:03 UTC, John Colvin wrote:

 On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
 wrote:

 Discuss: 
 https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


 Kill it. Eventually we may be able to reclaim it as something 
 more useful.



There are some well reasoned arguments for keeping it expressed 
in this thread. I would personally be happy with Andrei's 
compromise.
Mar 24 2014
prev sibling next sibling parent "Mike James" <foo bar.com> writes:
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


Yep. In the interests of clarity, kill the comma...
Mar 23 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/23/14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399


Some previous discussions:

comma operator causes hard to spot bugs
http://forum.dlang.org/thread/jmu8sg$2b2q$1 digitalmars.com?page=1

DIP19: Remove comma operator from D and provision better syntactic
support for tuples
http://forum.dlang.org/thread/k3ns2a$1ndc$1 digitalmars.com?page=1
Mar 23 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399


+1.

Bye,
bearophile
Mar 23 2014
prev sibling next sibling parent "Philpax" <phillip philliplarkson.com> writes:
Kill it with fire. It has no purpose in D.
Mar 23 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Should we deprecate comma?


Yes, please.
Mar 23 2014
prev sibling next sibling parent =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 2014-03-23 20:56, Andrei Alexandrescu wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


I'd shed no tears if the comma operator were gone.

--
   Simen
Mar 23 2014
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


You mentioned on the Github PR that this broke some Phobos (and 
Druntime?) code. What was the extent of the breakage? If it's 
small, I'd say give it a year-long deprecation period and then be 
done with it forever.
Mar 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/23/14, 5:41 PM, Meta wrote:

 On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


 You mentioned on the Github PR that this broke some Phobos (and
 Druntime?) code. What was the extent of the breakage? If it's small, I'd
 say give it a year-long deprecation period and then be done with it
 forever.


The extent of the breakage is NOT among the top factors. Once a piece of 
code goes from "compiles" to "doesn't compile" that lowers the 
acceptance level by an order of magnitude. Only after that, the extent 
of the breakage has any import.

Top factors:

0. Any silent breakages or changes in semantics? 100000000x

1. How frequent is the breakage? Is most code going to still work? 100x

2. How much does fixing the breakage improve code? Was the breaking code 
incorrect for the most part? 100x


Andrei
Mar 23 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 The extent of the breakage is NOT among the top factors. Once a 
 piece of code goes from "compiles" to "doesn't compile" that 
 lowers the acceptance level by an order of magnitude. Only 
 after that, the extent of the breakage has any import.


Are you going to ignore the voices in this thread? If that's 
true, what's the point of asking to the newsgroup? Perhaps just 
to collect few people that agree with you, to show you are 
listening?

Bye,
bearophile
Mar 23 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/23/14, 6:18 PM, bearophile wrote:

 Andrei Alexandrescu:


 The extent of the breakage is NOT among the top factors. Once a piece
 of code goes from "compiles" to "doesn't compile" that lowers the
 acceptance level by an order of magnitude. Only after that, the extent
 of the breakage has any import.


 Are you going to ignore the voices in this thread?


I'm not going to ignore good argument made by the voices in this thread. 
-- Andrei
Mar 23 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/23/14, 6:18 PM, bearophile wrote:

 Andrei Alexandrescu:


 The extent of the breakage is NOT among the top factors. Once a piece
 of code goes from "compiles" to "doesn't compile" that lowers the
 acceptance level by an order of magnitude. Only after that, the extent
 of the breakage has any import.


 Are you going to ignore the voices in this thread? If that's true,
 what's the point of asking to the newsgroup? Perhaps just to collect few
 people that agree with you, to show you are listening?


And by the way the irony here is that you seem to ignore my argument.

Andrei
Mar 23 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 And by the way the irony here is that you seem to ignore my 
 argument.


Yes, sorry, politics is not for me. Better to go back discussing 
technical matters.



Some examples of what you're trying to achieve would be great,<


Tuples are simple entities, so in past threads I have given 
examples of all my usages cases. If you want I can copy them 
again here (usage examples don't ask for a specific syntax, they 
are just about the desired semantics).



with the understanding that you're looking at at least five 
years until we'd be able to change anything about the use of 
comma.<


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.

I want to remove comma operators from D to avoid bugs and to make 
D code more readable. For me those are very important things, 
more important than the little code breaking it causes.

Bye,
bearophile
Mar 23 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Mar 23 2014
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Mar 24 2014
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 24 March 2014 at 00:59:00 UTC, Andrei Alexandrescu 
wrote:

 On 3/23/14, 5:41 PM, Meta wrote:

 On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
 wrote:

 Discuss: 
 https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


 You mentioned on the Github PR that this broke some Phobos (and
 Druntime?) code. What was the extent of the breakage? If it's 
 small, I'd
 say give it a year-long deprecation period and then be done 
 with it
 forever.


 The extent of the breakage is NOT among the top factors. Once a 
 piece of code goes from "compiles" to "doesn't compile" that 
 lowers the acceptance level by an order of magnitude. Only 
 after that, the extent of the breakage has any import.

 Top factors:

 0. Any silent breakages or changes in semantics? 100000000x


None in this case.


 1. How frequent is the breakage? Is most code going to still 
 work? 100x


Very infrequent, judging by other peoples' repsonses here, and 
the fact that there were only a handful of places in all of 
druntime and Phobos.


 2. How much does fixing the breakage improve code? Was the 
 breaking code incorrect for the most part? 100x


As I wrote elsewhere, my main motivation for the PR was enabling 
a possible future tuple literal syntax, multiple return values, 
unpacking assignment and the like. The gains were therefore not 
so much in detecting wrong code, although apparently there is 
some from time to time:
https://d.puremagic.com/issues/show_bug.cgi?id=2659
Mar 24 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/24/14, 5:35 AM, "Marc Schütz" <schuetzm gmx.net>" wrote:

 1. How frequent is the breakage? Is most code going to still work? 100x


 Very infrequent, judging by other peoples' repsonses here, and the fact
 that there were only a handful of places in all of druntime and Phobos.


Breaking druntime and phobos in multiple places counts as very frequent. 
-- Andrei
Mar 24 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399


Are you going to listen to people in this thread or are just 
going to say that people in the newsgroup are not representative 
of the whole community of D users?

Regarding the "progress", I'd like a good built-in syntax to 
unpack tuples in assignments, inside function signatures, in 
foreach statements, and more, because the syntactic contortions I 
currently adopt to use tuples in D are bad.

Bye,
bearophile
Mar 23 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/23/14, 6:09 PM, bearophile wrote:

 Andrei Alexandrescu:


 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399


 Are you going to listen to people in this thread or are just going to
 say that people in the newsgroup are not representative of the whole
 community of D users?


Argumentum ad populum has low pull on me. Come with good arguments, not 
"half a dozen people can't be wrong".


 Regarding the "progress", I'd like a good built-in syntax to unpack
 tuples in assignments, inside function signatures, in foreach
 statements, and more, because the syntactic contortions I currently
 adopt to use tuples in D are bad.


Some examples of what you're trying to achieve would be great, with the 
understanding that you're looking at at least five years until we'd be 
able to change anything about the use of comma.


Andrei
Mar 23 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 24 March 2014 at 01:16:47 UTC, Andrei Alexandrescu 
wrote:

 On 3/23/14, 6:09 PM, bearophile wrote:

 Andrei Alexandrescu:


 Discuss: 
 https://github.com/D-Programming-Language/dmd/pull/3399


 Are you going to listen to people in this thread or are just 
 going to
 say that people in the newsgroup are not representative of the 
 whole
 community of D users?


 Argumentum ad populum has low pull on me. Come with good 
 arguments, not "half a dozen people can't be wrong".


It is understood, but this has been discussed to death, and 
yourself agreed in the past that this was to be done.

The topic has been recurrent for 5 years. It could have been 
through the deprecation process several time by now.

Points goes as follow :
  - This construct has little usefulness.
  - It create hard to debug bugs (if you switch , and ; in typo 
for instance).
  - It prevents moving forward with tuples/multiple returns value 
with a nice syntax.
  - Most people hate it.

Why is that we need to either cast thing in stone or change by 
breaking everything Atila style ? The more we wait, the greater 
the pain.
Mar 23 2014
parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
Here's another.
https://d.puremagic.com/issues/show_bug.cgi?id=2659

Also, kill it with fire.

I do use it, but only in incomprehensible C++ algorithm 
competitions, where it saves a few strokes. Everywhere else it 
has only been a nasty surprise.
Mar 23 2014
prev sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
2014-03-24 10:09 GMT+09:00 bearophile <bearophileHUGS lycos.com>:


 Andrei Alexandrescu:

  Discuss: https://github.com/D-Programming-Language/dmd/pull/3399


 Regarding the "progress", I'd like a good built-in syntax to unpack tuples
 in assignments, inside function signatures, in foreach statements, and
 more, because the syntactic contortions I currently adopt to use tuples in
 D are bad.


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.

   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

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.

Kenji Hara



 Mar 23 2014



 next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Kenji Hara" <k.hara.pg gmail.com> wrote in message 
news:mailman.27.1395624482.25518.digitalmars-d puremagic.com...
2014-03-24 10:09 GMT+09:00 bearophile <bearophileHUGS lycos.com>:


     if (cond) exp1, exp2;   // in most case, this is not a bug.


It's not a bug, but this does the same thing - so why use the comma 
operator?

if (cond) { exp1; exp2; }

It catches bugs that are otherwise very difficult to spot. 



 Mar 23 2014



  parent reply Kenji Hara <k.hara.pg gmail.com>  writes:


2014-03-24 10:38 GMT+09:00 Daniel Murphy <yebbliesnospam gmail.com>:


 "Kenji Hara" <k.hara.pg gmail.com> wrote in message
 news:mailman.27.1395624482.25518.digitalmars-d puremagic.com...

 2014-03-24 10:09 GMT+09:00 bearophile <bearophileHUGS lycos.com>:

      if (cond) exp1, exp2;   // in most case, this is not a bug.


 It's not a bug, but this does the same thing - so why use the comma
 operator?

 if (cond) { exp1; exp2; }

 It catches bugs that are otherwise very difficult to spot.


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



 Mar 23 2014



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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.


Andrei



 Mar 23 2014



 next sibling parent  "Meta" <jared771 gmail.com>  writes:


On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu 
wrote:

 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.


 Andrei


That's a good idea. I never personally use the comma operator, as 
I think that it makes code less readable having multiple 
expressions evaluated on a single line. For the same reason, I 
almost never put multiple semicolon-delimited statements on the 
same line. Code like the above I find particularly egregious. It 
plays havoc with the programmer's expectation that they can parse 
the code left-to-right to figure out the result of an expression, 
forcing them to read in spirals. This is just as bad as the 
pointer declaration syntax for C/C++, just not as common.



 Mar 23 2014



prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Andrei Alexandrescu"  wrote in message 
news:lgo5ei$1tne$1 digitalmars.com...


 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.


I could live with that, although I'd still rather see it die. 



 Mar 23 2014



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 7:45 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:lgo5ei$1tne$1 digitalmars.com...


 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.


 I could live with that, although I'd still rather see it die.


Boil the frog slowly. -- Andrei



 Mar 23 2014



prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu 
wrote:

 One concession we could make would be to disallow using the 
 result of the operator. That might actually catch all bugs 
 discussed herein.


If we go that far, we might as well just kill the whole thing, 
since half* the reason of using an expression in the first place 
is to use the result. Otherwise, you might as well use a 
statement.

if (condition) ++i, ++j; // might as well be { ++i; ++j; }

* The other half of the uses being where you want a statement, 
but the grammar won't allow it... but even in those cases, the 
ONLY time I can think of where this is the case AND you don't 
need the result is the increment expression of the for loop.

So with that compromise, it is equivalent to banning the comma 
expression except in the special case of the for loop and in code 
that has no real reason to use it in the first place (and is also 
the most likely place where it was used unintentionally).

** Concrete example of where I (/very/ rarely apparently) 
consciously use the comma operator:

int a = something == 1 ? 1
       : something == 2 ? 2
       : (assert(0), 0);

There, I want the assert(0) to trigger in the default case, but 
the ternary operator still needs a value to assign to the 
variable a, so the ,0 provides that. Never actually used, but 
required for the common type of the ternary to match up.



 Mar 23 2014



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 24 March 2014 at 02:50:18 UTC, Adam D. Ruppe wrote:

 (and is also the most likely place where it was used 
 unintentionally).



Actually, this is overreaching, the if(function(call), misplaced) 
is probably the most likely place it is used unintentionally.

But still, if we make this change at all, I see no reason to keep 
if(a) b, c; given the extreme rarity of that case and the ease 
with which i can be replaced with if(a) { b; c; }

I'd prefer to remove it entirely over keeping this compromise.



 Mar 23 2014



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 8:04 PM, Adam D. Ruppe wrote:

 But still, if we make this change at all, I see no reason to keep if(a)
 b, c; given the extreme rarity of that case and the ease with which i
 can be replaced with if(a) { b; c; }


Same misunderstanding all over again. Please understand that breaking 
code is the worst thing. Arguing that the breakage is easy to fix 
doesn't help that most important part.

Andrei



 Mar 23 2014



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 7:50 PM, Adam D. Ruppe wrote:

 On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu wrote:

 One concession we could make would be to disallow using the result of
 the operator. That might actually catch all bugs discussed herein.


 If we go that far, we might as well just kill the whole thing, since
 half* the reason of using an expression in the first place is to use the
 result.


1. I don't think that's half at all.

2. The fraction we'd disallow contains virtually all bugs that were 
discussed (in addition of course to legitimate cases)


Andrei



 Mar 23 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Andrei Alexandrescu:


 2. The fraction we'd disallow contains virtually all bugs that 
 were discussed (in addition of course to legitimate cases)


Including the actual bug found in Phobos? I can't find it now...

Bye,
bearophile



 Mar 23 2014



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 8:12 PM, bearophile wrote:

 Andrei Alexandrescu:


 2. The fraction we'd disallow contains virtually all bugs that were
 discussed (in addition of course to legitimate cases)


 Including the actual bug found in Phobos? I can't find it now...


Yes, can't find it now. It was something like:

foreach (e; chain(iota('a', 'я')), iota('A', 'Я') {
    ...
}

Andrei



 Mar 23 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 8:12 PM, bearophile wrote:

 Andrei Alexandrescu:


 2. The fraction we'd disallow contains virtually all bugs that were
 discussed (in addition of course to legitimate cases)


 Including the actual bug found in Phobos? I can't find it now...


Yes, can't find it now. It was something like:

foreach (e; chain(iota('a', 'я')), iota('A', 'Я')) {
    ...
}

Andrei



 Mar 23 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Andrei Alexandrescu:


 Yes, can't find it now. It was something like:

 foreach (e; chain(iota('a', 'я')), iota('A', 'Я')) {
    ...
 }


Then if all or most comma-related bugs are caught with a more 
limited language change, then it's an interesting thing to know. 
Minimizing change impact is often positive.

How is this more limited change affecting possible future syntax 
usage of commas for tuples? :-)

Bye,
bearophile



 Mar 23 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Mar 23 2014



 next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


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


That is brilliant ! I'm buying.



 Mar 23 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


deadalnix:


 Andrei Alexandrescu:

 The change has an eye to that. Disallowing the use of the 
 return value offers us the future possibility of redefining 
 it. -- Andrei


 That is brilliant ! I'm buying.


Please show few examples. I am not sure using the comma for 
tuples in just return situations is a good idea. It seems too 
much special casing. Also because returning tuples is already 
currently acceptable. The main problem is breaking tuples apart.

Bye,
bearophile



 Mar 23 2014



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 24 March 2014 at 05:18:04 UTC, bearophile wrote:

 deadalnix:


 Andrei Alexandrescu:

 The change has an eye to that. Disallowing the use of the 
 return value offers us the future possibility of redefining 
 it. -- Andrei


 That is brilliant ! I'm buying.


 Please show few examples. I am not sure using the comma for 
 tuples in just return situations is a good idea. It seems too 
 much special casing. Also because returning tuples is already 
 currently acceptable. The main problem is breaking tuples apart.


I actually made a more complete explanation of what I have in 
mind. I should probably write a DIP one day.

You can read a rough explanation of my proposal here:
http://forum.dlang.org/thread/lrycaqlrtwylhbxfifyz forum.dlang.org?page=2#post-mudvqeqzbosfdirtfkhr:40forum.dlang.org



 Mar 23 2014



prev sibling  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


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.



 Mar 24 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/24/14, 5:18 AM, "Marc Schütz" <schuetzm gmx.net>" wrote:

 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.


No, parsing stays the same. You can think of comma returning a tuple. 
But for now we're forcing that tuple to never be used, so as to not 
change code semantics.

Andrei



 Mar 24 2014



  parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Monday, 24 March 2014 at 16:38:42 UTC, Andrei Alexandrescu 
wrote:

 On 3/24/14, 5:18 AM, "Marc Schütz" <schuetzm gmx.net>" wrote:

 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.


 No, parsing stays the same. You can think of comma returning a 
 tuple. But for now we're forcing that tuple to never be used, 
 so as to not change code semantics.


Ah, that's clever.



 Mar 24 2014



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 7:50 PM, Adam D. Ruppe wrote:

 int a = something == 1 ? 1
        : something == 2 ? 2
        : (assert(0), 0);


That was in Phobos too. Fix:

int a = something == 1 ? 1
        : something == 2 ? 2
        : { assert(0); return 0; }();

There are of course other ways, too, including defining a function that 
returns its last argument.


Andrei



 Mar 23 2014



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 24 March 2014 at 03:09:46 UTC, Andrei Alexandrescu 
wrote:

 That was in Phobos too. Fix:


Same misunderstanding all over again. Please understand that 
breaking code is the worst thing.

(yes, I'm quoting you back from a future message, but my point is 
that the compromise breaks code just like the full-blown 
deprecation, while leaving very little value behind.)


 There are of course other ways, too, including defining a 
 function that returns its last argument.


Actually, that won't work. Since assert(0) returns void, it is 
not a valid function parameter.

But it could also be rewritten as a switch statement. So if the 
code is broken, one way or another we'd have to change that 
pattern but it is doable, so not the end of the world.



 Mar 23 2014



  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Adam D. Ruppe"  wrote in message 
news:kuyoqpmqvevpkpzdxsxq forum.dlang.org...


 There are of course other ways, too, including defining a function that 
 returns its last argument.


 Actually, that won't work. Since assert(0) returns void, it is not a valid 
 function parameter.


lazy void 



 Mar 24 2014



prev sibling  parent reply Byron <byron.heads gmail.com>  writes:


On Sun, 23 Mar 2014 20:09:45 -0700, Andrei Alexandrescu wrote:

 
 That was in Phobos too. Fix:
 
 int a = something == 1 ? 1
         : something == 2 ? 2 : { assert(0); return 0; }();
 
 There are of course other ways, too, including defining a function that
 returns its last argument.
 
 
 Andrei


This would be a red flag in my code review, nested ternaries are to hard 
to read and even worse for maintainability.  Been bit to many times with 
little bugs in them.  Wish compilers would throw a warning when they are 
used.   



 Mar 25 2014



 next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Byron:


 nested ternaries are to hard to read and even worse for
 maintainability.  Been bit to many times with little bugs
 in them.  Wish compilers would throw a warning when they
 are used.


Perhaps related:
https://d.puremagic.com/issues/show_bug.cgi?id=8757

On the other hand chained ternary operators are not too much 
uncommon.

Bye,
bearophile



 Mar 25 2014



prev sibling  parent  "Kagamin" <spam here.lot>  writes:


On Tuesday, 25 March 2014 at 14:00:28 UTC, Byron wrote:

 On Sun, 23 Mar 2014 20:09:45 -0700, Andrei Alexandrescu wrote:

 
 That was in Phobos too. Fix:
 
 int a = something == 1 ? 1
         : something == 2 ? 2 : { assert(0); return 0; }();
 
 There are of course other ways, too, including defining a 
 function that
 returns its last argument.
 
 
 Andrei


 This would be a red flag in my code review, nested ternaries 
 are to hard
 to read and even worse for maintainability.  Been bit to many 
 times with
 little bugs in them.  Wish compilers would throw a warning when 
 they are
 used.


We use chained ternaries in our code regularly, and had no 
problem with them, with more than average programmers on the 
project. In my experience syntax didn't cause a single bug.



 Mar 26 2014



prev sibling  parent  "Regan Heath" <regan netmail.co.nz>  writes:


On Mon, 24 Mar 2014 02:50:17 -0000, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 int a = something == 1 ? 1
        : something == 2 ? 2
        : (assert(0), 0);


FWIW I personally find this kind of code horrid.  I would re-write to:

assert  (something == 1 || something == 2);
int a = (something == 1 || something == 2) ? something : 0;

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Mar 24 2014



prev sibling next sibling parent reply "Asman01" <jckj33 gmail.com>  writes:


On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu 
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.


 Andrei


I could live with that too but I suggest to extend if(condition) 
to allow assignment too:

if(condition) x = 2, y = 3; // fine
if(condition) f(),x=3; // ERRROR

What do you think?



 Mar 23 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 7:54 PM, Asman01 wrote:

 if(condition) x = 2, y = 3; // fine
 if(condition) f(),x=3; // ERRROR

 What do you think?


Too quirky -- Andrei



 Mar 23 2014



  parent  "Asman01" <jckj33 gmail.com>  writes:


On Monday, 24 March 2014 at 03:10:23 UTC, Andrei Alexandrescu 
wrote:

 On 3/23/14, 7:54 PM, Asman01 wrote:

 if(condition) x = 2, y = 3; // fine
 if(condition) f(),x=3; // ERRROR

 What do you think?


 Too quirky -- Andrei


True. I don't want to make a kind of C++



 Mar 23 2014



prev sibling next sibling parent reply Etienne Cimon <etcimon gmail.com>  writes:


On 2014-03-23 22:31, Andrei Alexandrescu 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.


 Andrei


How about allowing it only inside parenthesis?

e.g.


if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
if((pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw)) // OK
return (pMgr->RecordEvent(eSE_Weapon), pOwnerRaw); // OK



 Mar 23 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Mar 23 2014



 next sibling parent reply Etienne Cimon <etcimon gmail.com>  writes:


On 2014-03-24 00:04, 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


If the comma expression operator is outlawed on the global scope, 
variadic template parameters could be used with commas outside the 
parantheses which allows such syntax:

if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK
return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK

Would it make sense to reserve the global e identifier for expressions?

I'd be happy to see commas go and eventually wake up to this in a few 
years, also enabling what would seem like a new kind of comma operator 
overloading



 Mar 23 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 9:29 PM, Etienne Cimon wrote:

 On 2014-03-24 00:04, 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


 If the comma expression operator is outlawed on the global scope,
 variadic template parameters could be used with commas outside the
 parantheses which allows such syntax:

 if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
 return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
 if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK
 return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK

 Would it make sense to reserve the global e identifier for expressions?


With that the approach would be veering off the road. -- Andrei



 Mar 23 2014



  parent  Etienne Cimon <etcimon gmail.com>  writes:


On 2014-03-24 00:41, Andrei Alexandrescu wrote:

 On 3/23/14, 9:29 PM, Etienne Cimon wrote:

 On 2014-03-24 00:04, 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


 If the comma expression operator is outlawed on the global scope,
 variadic template parameters could be used with commas outside the
 parantheses which allows such syntax:

 if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
 return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
 if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK
 return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK

 Would it make sense to reserve the global e identifier for expressions?


 With that the approach would be veering off the road. -- Andrei


Well, I'll vote for the compromise, there shouldn't be issues with 
keeping statements in void contexts such as
int i, j, k;
i++, j++, k--;
etc.

And then I guess I'll change that part of my coding style, everyone 
seems to hate it so much ..



 Mar 23 2014



prev sibling  parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


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.



 Mar 24 2014



prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu 
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.


I like it a lot. Almost *all* the "abusive" uses of "operator 
comma" I've seen use this trait of operator comma. So this would 
kill those:
//----
auto a = fun(), 5; //WTF is wrong with you?
//----

On the other hand, the "legit" cases of comma never seem to use 
the return value. The "only" execute two statements in a single 
context. For example:

//----
for (size_t i, j ; someCondition() ; ++i, ++j )
{...}
//----

I think this is *the* single most common use of operator comma, 
and I also think it is perfectly legit. Sure, it can easily be 
migrated away from, but I think it would be gratuitous breakage 
of good code.

--------

So this has my +1 vote.



 Mar 24 2014



  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Monday, 24 March 2014 at 09:09:30 UTC, monarch_dodra wrote:

 //----
 for (size_t i, j ; someCondition() ; ++i, ++j )
 {...}
 //----

 I think this is *the* single most common use of operator comma, 
 and I also think it is perfectly legit. Sure, it can easily be 
 migrated away from, but I think it would be gratuitous breakage 
 of good code.


Legit but largely useless.
In every cases I've seen where this idiom appears, you can derive 
j from i and the compiler is able to generate the very same code.



 Mar 24 2014



  parent  "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 24 March 2014 at 09:13:39 UTC, ponce wrote:

 On Monday, 24 March 2014 at 09:09:30 UTC, monarch_dodra wrote:

 //----
 for (size_t i, j ; someCondition() ; ++i, ++j )
 {...}
 //----

 I think this is *the* single most common use of operator 
 comma, and I also think it is perfectly legit. Sure, it can 
 easily be migrated away from, but I think it would be 
 gratuitous breakage of good code.


 Legit but largely useless.
 In every cases I've seen where this idiom appears, you can 
 derive j from i and the compiler is able to generate the very 
 same code.


I've seen plenty of cases where you can't, such as most 
algorithms that "copy filter" or "copy remove". Further, 
especially with ranges, you can't derive one from the other. The 
code usually becomes:

for ( ; someCondition() ; r1.popFront(), r2.popFront() )



 Mar 24 2014



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


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



 Mar 24 2014



  parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 24 March 2014 at 12:32:30 UTC, Steven Schveighoffer 
wrote:

 On Sun, 23 Mar 2014 22:31:25 -0400, Andrei Alexandrescu 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


//----
if(cond)
     {exp; exp2;}
//----

?

For what it's worth, it's what we do in our production code. And 
it's safer. A copy paste that produces:
//----
if(cond)
     exp; exp2;
//----

Can happen so fast, and is virtually un-catcheable unless it 
actually breaks something.



 Mar 24 2014



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 24 Mar 2014 08:38:14 -0400, monarch_dodra <monarchdodra gmail.com>  
wrote:


 On Monday, 24 March 2014 at 12:32:30 UTC, Steven Schveighoffer wrote:

 On Sun, 23 Mar 2014 22:31:25 -0400, Andrei Alexandrescu 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


 //----
 if(cond)
      {exp; exp2;}
 //----

 ?

 For what it's worth, it's what we do in our production code. And it's  
 safer. A copy paste that produces:
 //----
 if(cond)
      exp; exp2;
 //----

 Can happen so fast, and is virtually un-catcheable unless it actually  
 breaks something.


I have an allergic reaction to braces on the same lines :) Only place I  
ever use them is when the whole function can fit on the same line.

-Steve



 Mar 24 2014



  parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 24 March 2014 at 12:43:22 UTC, Steven Schveighoffer 
wrote:

 I have an allergic reaction to braces on the same lines :) Only 
 place I ever use them is when the whole function can fit on the 
 same line.

 -Steve


I get that "allergic reaction" :)

But it does have its advantages in terms of robustness 
(accidental ";"), and scaling. For example, there are cases where 
"," can't be used:

Type myType;
if(cond)
     {int dummy = 5; initialize(myType, dummy);}

As a general rule, I feel that "{}" is ugly, but that once they 
are there, no-one is going to break my code.



 Mar 24 2014



  parent  Nick Treleaven <ntrel-public yahoo.co.uk>  writes:


On 24/03/2014 13:10, monarch_dodra wrote:

 On Monday, 24 March 2014 at 12:43:22 UTC, Steven Schveighoffer wrote:

 I have an allergic reaction to braces on the same lines :) Only place
 I ever use them is when the whole function can fit on the same line.




+1, I wish we could write:
T fun() => result;

Discussion here:
https://d.puremagic.com/issues/show_bug.cgi?id=7176


 I get that "allergic reaction" :)

 But it does have its advantages in terms of robustness (accidental ";"),
 and scaling. For example, there are cases where "," can't be used:

 Type myType;
 if(cond)
      {int dummy = 5; initialize(myType, dummy);}


Here I would just use several lines for better readability. I would only 
use the comma for simple expressions that don't depend on each other:

if (cond)
	x=5, y=6;


 As a general rule, I feel that "{}" is ugly, but that once they are
 there, no-one is going to break my code.





 Mar 24 2014



prev sibling  parent  "Asman01" <jckj33 gmail.com>  writes:


On Monday, 24 March 2014 at 02:21:20 UTC, Kenji Hara wrote:

 2014-03-24 10:38 GMT+09:00 Daniel Murphy 
 <yebbliesnospam gmail.com>:


 "Kenji Hara" <k.hara.pg gmail.com> wrote in message
 news:mailman.27.1395624482.25518.digitalmars-d puremagic.com...

 2014-03-24 10:09 GMT+09:00 bearophile 
 <bearophileHUGS lycos.com>:

      if (cond) exp1, exp2;   // in most case, this is not a 
 bug.


 It's not a bug, but this does the same thing - so why use the 
 comma
 operator?

 if (cond) { exp1; exp2; }

 It catches bugs that are otherwise very difficult to spot.


 At least I can imagine two reasonable cases.

 1. If the code is ported from C/C++, breaking it is not 
 reasonable.



 Kenji Hara


What about the compiler make some effort to detect this usage and 
suggests the appropriated solution? just like it does when using 
C's array/cast style. i.e., split the expression separed by the 
comma operator in a list of expressions separed by semicolon 
inside a compund statement. It isn't too hard to implement.



 Mar 23 2014



prev sibling next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Kenji Hara:


 1. I think removing comma operator does not have useful effect 
 for tuple syntax discussion.


I agree, see my recent answer to Andrei.



 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 I see a foreach like that, I refactor the code to remove the 
comma. Apparently I am not very good at keeping the semantics of 
the comma operator in my head, so I prefer to kill them in the 
code I work on.

Bye,
bearophile



 Mar 23 2014



prev sibling next sibling parent  "Asman01" <jckj33 gmail.com>  writes:


     if (cond) exp1, exp2;   // in most case, this is not a bug.

    So, completely removing comma operator will cause negative 
 affect in
 some cases.

 Kenji Hara


In this case you should use { exp1; exp2; } There's two 
expressions, so same number of ';' should appear and it make code 
more clean. I know it's personal. It's just IMHO.



 Mar 23 2014



prev sibling next sibling parent  "ponce" <contact gam3sfrommars.fr>  writes:


On Monday, 24 March 2014 at 01:28:02 UTC, Kenji Hara wrote:

     if (cond) exp1, exp2;   // in most case, this is not a bug.


I fail to see how is this useful. It looks way harder to 
comprehend, because first you have to recognize a comma operator 
has been used (rare), and then you have to understand why it was 
used (and it's always avoidable).

If using C++, such a code would trigger a static analyzer warning.



 Mar 24 2014



prev sibling  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


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).



 Mar 24 2014



 next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


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



 Mar 24 2014



 next sibling parent reply "w0rp" <devw0rp gmail.com>  writes:


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.



 Mar 24 2014



 next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Monday, 24 March 2014 at 12:25:58 UTC, w0rp wrote:

 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.


I'm not familiar with Python. What is the difference between a 
one-element tuple and an expression? Are Python tuples just 
arrays?



 Mar 24 2014



 next sibling parent reply "w0rp" <devw0rp gmail.com>  writes:


On Monday, 24 March 2014 at 12:39:53 UTC, Marc Schütz wrote:

 On Monday, 24 March 2014 at 12:25:58 UTC, w0rp wrote:

 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.


 I'm not familiar with Python. What is the difference between a 
 one-element tuple and an expression? Are Python tuples just 
 arrays?


Consider the following.


 (1, 2)






(1, 2)


 (1)






1


 (1 * (3 * 4,))






(-1, )


 (1 * (3 - 4,) * 2)






(-1, -1)


 foo = lambda : 3







 (






...     foo()
... )

3


 (






...     foo(),
... )

(3, )

I see this kind of confusion happen often, and the convenient 
syntax becomes a burden.



 Mar 24 2014



  parent  Russel Winder <russel winder.org.uk>  writes:


On Mon, 2014-03-24 at 13:00 +0000, w0rp wrote:
[…]

 
 Consider the following.
 

 (1, 2)






 
 (1, 2)
 

 (1)






 
 1
 

 (1 * (3 * 4,))






 
 (-1, )
 

 (1 * (3 - 4,) * 2)






 
 (-1, -1)
 

 foo = lambda : 3






 

 (






 ...     foo()
 ... )
 
 3
 

 (






 ...     foo(),
 ... )
 
 (3, )
 
 I see this kind of confusion happen often, and the convenient 
 syntax becomes a burden.


The moral of the story is that if you want to avoid the situation Python
is in, then do not use ( and ) as delimiters for expressions and also
something else semantically different.
 
-- 
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



 Mar 24 2014



prev sibling  parent  Russel Winder <russel winder.org.uk>  writes:


On Mon, 2014-03-24 at 12:39 +0000, Marc =?UTF-8?B?U2Now7x0eiI=?=
 puremagic.com wrote:
[…]

 I'm not familiar with Python. What is the difference between a 
 one-element tuple and an expression? Are Python tuples just 
 arrays?


Tuples are sequences, expressions are scalars: a tuple is effectively an
immutable list.

-- 
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



 Mar 24 2014



prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


w0rp:


 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.


I agree, 1-tuples in Python are tricky. Compare it with the clear 
Python list literal syntax:

[]        => 0-length list
[1]       => 1-length list
[1, 2]    => 2-length list
[1, 2, 3] => 2-length list

Unfortunately ASCII offers a limited choice of delimiters :-)



 I don't have an alternative syntax to propose.


Look at some of the syntaxes here:
http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax

One of the syntaxes:

 {}
 {a}
 {a, b}
 {a, b, c}

Bye,
bearophile



 Mar 24 2014



 next sibling parent reply Russel Winder <russel winder.org.uk>  writes:


On Mon, 2014-03-24 at 12:44 +0000, bearophile wrote:
[…]

 I agree, 1-tuples in Python are tricky. Compare it with the clear 
 Python list literal syntax:
 
 []        => 0-length list
 [1]       => 1-length list
 [1, 2]    => 2-length list
 [1, 2, 3] => 2-length list


But note that:

[1,]       => 1-length list
[1, 2,]    => 2-length list
[1, 2, 3,] => 2-length list

Do not underestimate the power of allowed trailing commas.

-- 
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



 Mar 24 2014



  parent  "bearophile" <bearophile HUGS lycos.com>  writes:


Russel Winder:


 But note that:

 [1,]       => 1-length list
 [1, 2,]    => 2-length list
 [1, 2, 3,] => 2-length list

 Do not underestimate the power of allowed trailing commas.


In Python it's ignored:


 [1,]






[1]

 [1, 2,]






[1, 2]

 [1, 2, 3,]






[1, 2, 3]

Bye,
bearophile



 Mar 24 2014



prev sibling next sibling parent  "Meta" <jared771 gmail.com>  writes:


On Monday, 24 March 2014 at 12:44:22 UTC, bearophile wrote:

 w0rp:


 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.


 I agree, 1-tuples in Python are tricky. Compare it with the 
 clear Python list literal syntax:

 []        => 0-length list
 [1]       => 1-length list
 [1, 2]    => 2-length list
 [1, 2, 3] => 2-length list

 Unfortunately ASCII offers a limited choice of delimiters :-)



 I don't have an alternative syntax to propose.


 Look at some of the syntaxes here:
 http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax

 One of the syntaxes:

  {}
  {a}
  {a, b}
  {a, b, c}

 Bye,
 bearophile


Do you know what Rust does in the case of 1-tuples?



 Mar 24 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/24/14, 5:44 AM, bearophile wrote:

 w0rp:


 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.


 I agree, 1-tuples in Python are tricky. Compare it with the clear Python
 list literal syntax:

 []        => 0-length list
 [1]       => 1-length list
 [1, 2]    => 2-length list
 [1, 2, 3] => 2-length list

 Unfortunately ASCII offers a limited choice of delimiters :-)



 I don't have an alternative syntax to propose.


 Look at some of the syntaxes here:
 http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax

 One of the syntaxes:

  {}
  {a}
  {a, b}
  {a, b, c}


WTF???

tuple()
tuple(a)
tuple(a, b)
tuple(a, b, c)


Andrei



 Mar 24 2014



 next sibling parent reply "bearophile" <bearophile HUGS lycos.com>  writes:


Andrei Alexandrescu:


 Look at some of the syntaxes here:
 http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax

 One of the syntaxes:

  {}
  {a}
  {a, b}
  {a, b, c}


 WTF???

 tuple()
 tuple(a)
 tuple(a, b)
 tuple(a, b, c)


 Andrei


So you are saying you want to support a syntax like this?

tuple(a, b, c) = myFunc();

Bye,
bearophile



 Mar 24 2014



 next sibling parent reply "bearophile" <bearophile HUGS lycos.com>  writes:


 So you are saying you want to support a syntax like this?

 tuple(a, b, c) = myFunc();


And:

foreach (tuple(a, b, c); myTuples) {}

void foo(in auto tuple(a, b, c)) {}

Bye,
bearophile



 Mar 24 2014



  parent  "Dicebot" <public dicebot.lv>  writes:


On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:

 void foo(in auto tuple(a, b, c)) {}


This snippet does not make any sense.



 Mar 24 2014



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 24 March 2014 at 16:57:09 UTC, bearophile wrote:

 So you are saying you want to support a syntax like this?

 tuple(a, b, c) = myFunc();

 Bye,
 bearophile


This actually almost works:

auto foo()
{
	return tuple(1, 2, 3);
}

void main()
{
	int a, b, c;
	
	tuple(a, b, c) = foo();
	writeln(a, b, c); // 000
	
	TypeTuple!(a, b, c) = foo();
	writeln(a, b, c); // 123
}



 Mar 24 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Dicebot:


 	int a, b, c;
 	
 	tuple(a, b, c) = foo();
 	writeln(a, b, c); // 000
 	
 	TypeTuple!(a, b, c) = foo();
 	writeln(a, b, c); // 123
 }


One of the points of a good tuple syntax is to not need to define 
the variables before (because in several cases you can't do that).



 On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:

 void foo(in auto tuple(a, b, c)) {}


 This snippet does not make any sense.


It's equivalent to Python2.6 code:

def foo((a, b, c)):


A more complete Python2.6 program:

def foo((a, b, c)):
     print a, "-", b, "-", c

t = (10, 20, 30)
foo(t)

Output:

10 - 20 - 30


In Haskell, OcaML, and other languages the code is similar. It's 
a tuple unpacking syntax in the function signature.

The other example with foreach is very similar.

Bye,
bearophile



 Mar 24 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 24 March 2014 at 17:35:46 UTC, bearophile wrote:

 Dicebot:


 	int a, b, c;
 	
 	tuple(a, b, c) = foo();
 	writeln(a, b, c); // 000
 	
 	TypeTuple!(a, b, c) = foo();
 	writeln(a, b, c); // 123
 }


 One of the points of a good tuple syntax is to not need to 
 define the variables before (because in several cases you can't 
 do that).


I understand but this is something that can be pretty hard to fit 
into D semantics/grammar and I am not sold that it is worth the 
push on its own.


 On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:

 void foo(in auto tuple(a, b, c)) {}


 This snippet does not make any sense.


 It's equivalent to Python2.6 code:

 def foo((a, b, c)):


 A more complete Python2.6 program:

 def foo((a, b, c)):
     print a, "-", b, "-", c

 t = (10, 20, 30)
 foo(t)

 Output:

 10 - 20 - 30


What is the difference with this then?

void foo(int a, int b, int c)
{
     // ...
}

auto t = tuple(10, 20, 30);
foo(t.expand);



 Mar 24 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Dicebot:


 I understand but this is something that can be pretty hard to 
 fit into D semantics/grammar and I am not sold that it is worth 
 the push on its own.


I'd like a good tuple syntax in D.



 What is the difference with this then?

 void foo(int a, int b, int c)
 {
     // ...
 }

 auto t = tuple(10, 20, 30);
 foo(t.expand);


The difference is that your experience with tuples will be less 
good. One difference can be seen here. Given an array of tuples 
(here I am using a shorter syntax):

auto arr = [ {1, 2},  (3, 4)]

You can't do this:

void foo(int a, int b, int c) {...}
auto result = arr.map!foo;

And you need:

auto result = arr.map!(t => foo(t.expand));

Or:

auto result = arr.map!(t => foo(t[]));


While you can do this:

void foo(in  (int a, int b, int c}) {...}
auto result = arr.map!foo;

The point of having a tuple syntax is not to expand the set of 
programs you can write with C language. It's of having a handy 
syntax to perform certain very common operations with more than 
one type.

I also suggest you to take a look at the DIP.

Bye,
bearophile



 Mar 24 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 24 March 2014 at 17:51:15 UTC, bearophile wrote:

 The difference is that your experience with tuples will be less 
 good. One difference can be seen here. Given an array of tuples 
 (here I am using a shorter syntax):

 auto arr = [ {1, 2},  (3, 4)]

 You can't do this:

 void foo(int a, int b, int c) {...}
 auto result = arr.map!foo;

 And you need:

 auto result = arr.map!(t => foo(t.expand));

 Or:

 auto result = arr.map!(t => foo(t[]));


 While you can do this:

 void foo(in  (int a, int b, int c}) {...}
 auto result = arr.map!foo;


I believe it is dangerous misfeature and I don't want to see this 
in D. Sorry :(



 Mar 24 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Dicebot:


 While you can do this:

 void foo(in  (int a, int b, int c}) {...}
 auto result = arr.map!foo;


 I believe it is dangerous misfeature and I don't want to see 
 this in D. Sorry :(


Why do you think it's a dangerous and a misfeature? I think you 
are misaken.

It's present in most functional languages, with slight syntax 
differences.

The problem is that it's hard to explain how much nice a language 
feature is if you have not used it extensively in some language 
:-) So I suggest you to try to write some functional code that 
uses plenty of tuples. You will see how commonly useful is what I 
have written :-)

A similar program in Haskell:


foo (a, b) =
     show a ++ " - " ++ show b

lst = [(10, 20), (30, 40)]

main = do
     print $ map foo lst


Output:

["10 - 20","30 - 40"]

And Haskell is regarded as one of the safest languages :-)



Bye,
bearophile



 Mar 24 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


 A similar program in Haskell:


 foo (a, b) =
     show a ++ " - " ++ show b

 lst = [(10, 20), (30, 40)]

 main = do
     print $ map foo lst


 Output:

 ["10 - 20","30 - 40"]

 And Haskell is regarded as one of the safest languages :-)




And in Rust:

fn first((value, _): (int, f64)) -> int { value }

Bye,
bearophile



 Mar 25 2014



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


"Comma operators should be used sparingly. The most suitable uses 
are for constructs strongly related to each other, as in the for 
loop in reverse, and in macros where a multistep computation has 
to be single expression." (K&R).

Kill it… D solves the use cases with other means.



 Mar 25 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/24/14, 9:57 AM, bearophile wrote:

 Andrei Alexandrescu:


 Look at some of the syntaxes here:
 http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax

 One of the syntaxes:

  {}
  {a}
  {a, b}
  {a, b, c}


 WTF???

 tuple()
 tuple(a)
 tuple(a, b)
 tuple(a, b, c)


 Andrei


 So you are saying you want to support a syntax like this?

 tuple(a, b, c) = myFunc();


That would be a different function but same syntax. In fact for safety I 
favor myFunc().scatter(a, b, c) -- Andrei



 Mar 24 2014



  parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Andrei Alexandrescu:


 That would be a different function but same syntax. In fact for 
 safety I favor myFunc().scatter(a, b, c) -- Andrei


That's awful :-) Are you now saying you don't want a good tuple 
unpacking syntax in D? Then what's the "eye to tuples" you were 
talking about regrding comma syntax?

Bye,
bearophile



 Mar 24 2014



prev sibling  parent reply Michel Fortin <michel.fortin michelf.ca>  writes:


On 2014-03-24 16:42:59 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 tuple()
 tuple(a)
 tuple(a, b)
 tuple(a, b, c)


struct()
struct(a)
struct(a, b)
struct(a, b, c)

Tuples are actually nameless structs, no?

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca



 Mar 24 2014



 next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Michel Fortin:


 struct()
 struct(a)
 struct(a, b)
 struct(a, b, c)

 Tuples are actually nameless structs, no?


That syntax is even longer/wordier :-)

auto arr = [struct(1, 2), struct(3, 4), struct(5, 6)];

Structs usually don't support slicing and concatenation. But they 
are indeed related structures.

Bye,
bearophile



 Mar 24 2014



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 24 March 2014 at 18:58:52 UTC, Michel Fortin wrote:

 On 2014-03-24 16:42:59 +0000, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:


 tuple()
 tuple(a)
 tuple(a, b)
 tuple(a, b, c)


 struct()
 struct(a)
 struct(a, b)
 struct(a, b, c)

 Tuples are actually nameless structs, no?


This whole point is that this part doesn't need any language 
semantic addition.

An unpacking syntax is a useful addition, and not especially 
related to tuples, as you could unpack arrays for instance.



 Mar 24 2014



  parent  "Joseph Cassman" <jc7919 outlook.com>  writes:


On Monday, 24 March 2014 at 20:04:23 UTC, deadalnix wrote:

 On Monday, 24 March 2014 at 18:58:52 UTC, Michel Fortin wrote:

 On 2014-03-24 16:42:59 +0000, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:


 tuple()
 tuple(a)
 tuple(a, b)
 tuple(a, b, c)


 struct()
 struct(a)
 struct(a, b)
 struct(a, b, c)

 Tuples are actually nameless structs, no?


 This whole point is that this part doesn't need any language 
 semantic addition.

 An unpacking syntax is a useful addition, and not especially 
 related to tuples, as you could unpack arrays for instance.


And would also avoid memory allocation where possible.
At least as far as unpacking the results of a function are 
concerned.

Joseph



 Mar 24 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/24/14, 5:25 AM, w0rp wrote:

 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.


How about

tuple(1,2)    two-element tuple
tuple(1)      one-element tuple
(1)           simple expression
tuple()       empty tuple

Oh, wait...


Andrei



 Mar 24 2014



 next sibling parent reply "w0rp" <devw0rp gmail.com>  writes:


On Monday, 24 March 2014 at 16:40:29 UTC, Andrei Alexandrescu 
wrote:

 On 3/24/14, 5:25 AM, w0rp wrote:

 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.


 How about

 tuple(1,2)    two-element tuple
 tuple(1)      one-element tuple
 (1)           simple expression
 tuple()       empty tuple

 Oh, wait...


 Andrei


Yes, I am with you on this. I prefer tuple(1) over (1, )



 Mar 24 2014



  parent  "bearophile" <bearophileHUGS lycos.com>  writes:


w0rp:


 Yes, I am with you on this. I prefer tuple(1) over (1, )


I don't think people are advocating for the "(1, )" syntax. 
Regarding the "tuple(1)" syntax, it is one of the alternative 
syntaxes you can find in the DIP. One disadvantage of the 
"tuple()" syntax is that it's a little long, so if you have an 
array of tuple literals it becomes a little wordy:

auto a = [tuple(1, 2), tuple(3, 4), tuple(5, 6)];

But of course having a good built-in "tuple()" syntax is much 
better than the current situation without any syntax.

Bye,
bearophile



 Mar 24 2014



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 24 March 2014 at 16:40:29 UTC, Andrei Alexandrescu 
wrote:

 How about

 tuple(1,2)    two-element tuple
 tuple(1)      one-element tuple
 (1)           simple expression
 tuple()       empty tuple

 Oh, wait...


Yes, that.



 Mar 24 2014



  parent  "bearophile" <bearophileHUGS lycos.com>  writes:


deadalnix:


 tuple(1,2)    two-element tuple
 tuple(1)      one-element tuple
 (1)           simple expression
 tuple()       empty tuple

 Oh, wait...


 Yes, that.


99% of the problem is not in the syntax to build tuples. What's 
desired are mostly syntaxes to do the opposite, pulling tuples 
apart in a handy way.

Bye,
berarophile



 Mar 24 2014



prev sibling  parent reply Russel Winder <russel winder.org.uk>  writes:


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



 Mar 24 2014



  parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Monday, 24 March 2014 at 12:31:16 UTC, Russel Winder wrote:

 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


I'm used to this now, but initially it stuck out like a sore 
thumb for a language that's supposed to be noob friendly. It gets 
the job done I suppose.



 Mar 24 2014



prev sibling  parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


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.)


On second thought, this would probably lead to problems in 
generic code, if we want to iterate over a tuple whose length we 
do not know, and which happens to have one element only. So there 
definitely needs to be a distinction between tuples and 
non-tuples.

But as this is about syntax only, the question is: Do we even 
need a dedicated syntax for one-element (and zero-element) 
tuples? When those are needed, they can easily be created using 
std.typecons.tuple(). The syntactic sugar is only really useful 
when we have multiple values, be it for returning or for 
assignment.



 Mar 24 2014



prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


My vote is no, though I don't feel strongly about it since I can 
still get work done either way; there's alternatives to the comma 
operator in every case I can think of in D. But I just don't see 
any compelling reason to make the change.

I don't find the tuple arguments convincing and the comma 
operator has not been a noteworthy source of bugs in my 
experience. The new tuple syntax need to outcompete the simple 
tuple() or TypeTuple!() possibilities we have today, and 
personally, I don't think they tuple proposals even stand on 
their own, much less outcompete the status quo.

So again, my position is no, leaning toward meh whatever.



 Mar 23 2014



  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Adam D. Ruppe"  wrote in message 
news:cchwhwpquenzkbuafule forum.dlang.org...


 My vote is no, though I don't feel strongly about it since I can still get 
 work done either way; there's alternatives to the comma operator in every 
 case I can think of in D. But I just don't see any compelling reason to 
 make the change.


The compelling reason is it catches bugs.  Try it on your code, you might be 
surprised!



 Mar 23 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 24 March 2014 at 01:48:15 UTC, Daniel Murphy wrote:

 Try it on your code, you might be surprised!


hmm, I am surprised about one thing: it didn't detect a single 
use of the comma operator in the ~10,000 lines of my code I fed 
it. I know I don't use it often, but I thought surely there'd be 
at least one or two uses in all that!

I'd compile my whole everything, but apparently I need to get git 
druntime* and phobos too for that to actually work (or patch my 
other dmd without getting the other changes) and meh, I don't 
care that much.

I guess it being even more rare than I thought moves me a bit 
more into "meh" territory though.



 Mar 23 2014



  parent  "Asman01" <jckj33 gmail.com>  writes:


On Monday, 24 March 2014 at 02:12:20 UTC, Adam D. Ruppe wrote:

 On Monday, 24 March 2014 at 01:48:15 UTC, Daniel Murphy wrote:

 Try it on your code, you might be surprised!


 hmm, I am surprised about one thing: it didn't detect a single 
 use of the comma operator in the ~10,000 lines of my code I fed 
 it. I know I don't use it often, but I thought surely there'd 
 be at least one or two uses in all that!


I think I've never used this. Seriously. Not even in PHP. To me 
it always a horrible thing.



 Mar 23 2014



prev sibling next sibling parent  "Asman01" <jckj33 gmail.com>  writes:


 From what I see on 
Wikipedia(http://en.wikipedia.org/wiki/Comma_operator) Go 
language has no comma operator.



 Mar 23 2014



prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com>  writes:


On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


If we kill this, it should be killed properly. I fear that we'll 
end up with some sort of half-dead zombie syntax like C-style 
array declarations.

http://d.puremagic.com/issues/show_bug.cgi?id=953



 Mar 23 2014



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/23/14, 8:58 PM, Brian Schott wrote:

 On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


 If we kill this, it should be killed properly. I fear that we'll end up
 with some sort of half-dead zombie syntax like C-style array declarations.

 http://d.puremagic.com/issues/show_bug.cgi?id=953


The comparison doesn't hold. -- Andrei



 Mar 23 2014



prev sibling  parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Brian Schott:


 http://d.puremagic.com/issues/show_bug.cgi?id=953


This is off-topic in this thread. But I think just disallowing 
mixed C/D declarations is a step forward:
http://d.puremagic.com/issues/show_bug.cgi?id=5807

I mean code like:

int[] a[];

Bye,
bearophile



 Mar 23 2014



prev sibling next sibling parent reply "Regan Heath" <regan netmail.co.nz>  writes:


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/



 Mar 24 2014



 next sibling parent reply "monarch_dodra" <monarchdodra gmail.com>  writes:


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.



 Mar 24 2014



  parent reply "Regan Heath" <regan netmail.co.nz>  writes:


On Mon, 24 Mar 2014 11:35:38 -0000, monarch_dodra <monarchdodra gmail.com>  
wrote:


 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.


That's my Q answered :)


 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.


I am well aware :p

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Mar 24 2014



  parent  "monarch_dodra" <monarchdodra gmail.com>  writes:


On Monday, 24 March 2014 at 14:49:09 UTC, Regan Heath wrote:

 On Mon, 24 Mar 2014 11:35:38 -0000, monarch_dodra 
 <monarchdodra gmail.com> wrote:


 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.


 That's my Q answered :)


 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.


 I am well aware :p


I thought so :) but this being a forum and all, "bad code" should 
always be tagged as such.



 Mar 24 2014



prev sibling  parent reply "Steve Teale" <steve.teale britseyeview.com>  writes:


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;

 R


I presume that

for (int i = 0, j = m;;) {}

Is in the same category?

The only place I have tended to use the comma operator is in 
ternary expressions

bool universal;

atq = whatever? 0: universal = true, 42;



 Mar 25 2014



 next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Steve Teale:


 The only place I have tended to use the comma operator is in 
 ternary expressions

 bool universal;

 atq = whatever? 0: universal = true, 42;


I classify that as quite tricky code, it's a negative example :-(

Bye,
bearophile



 Mar 25 2014



 next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 03/25/2014 02:08 PM, bearophile wrote:

 Steve Teale:


 The only place I have tended to use the comma operator is in ternary
 expressions

 bool universal;

 atq = whatever? 0: universal = true, 42;


 I classify that as quite tricky code, it's a negative example :-(

 Bye,
 bearophile


It's not tricky code. It is not even valid code. Operator precedence 
from lowest to highest: , = ?.



 Mar 25 2014



 next sibling parent reply "Regan Heath" <regan netmail.co.nz>  writes:


On Tue, 25 Mar 2014 13:15:16 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 03/25/2014 02:08 PM, bearophile wrote:

 Steve Teale:


 The only place I have tended to use the comma operator is in ternary
 expressions

 bool universal;

 atq = whatever? 0: universal = true, 42;


 I classify that as quite tricky code, it's a negative example :-(

 Bye,
 bearophile


 It's not tricky code. It is not even valid code. Operator precedence  
 from lowest to highest: , = ?.


Fixed:

atq = whatever ? 0 : (universal = true, 42);

Still a bad example.  Horrid code IMO.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Mar 25 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 25 March 2014 at 13:58:01 UTC, Regan Heath wrote:

 Fixed:

 atq = whatever ? 0 : (universal = true, 42);

 Still a bad example.  Horrid code IMO.

 R


Yeah, I'd likely object to it on code review and ask to re-write 
with plain if condition.



 Mar 25 2014



  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 3/25/14, Dicebot <public dicebot.lv> wrote:

 Yeah, I'd likely object to it on code review and ask to re-write
 with plain if condition.


This is my all-time favorite anti-feature:

void main()
{
    import std.stdio;
    bool False = false;
    writeln("the value is: " ~ False ? "true" : "false");
}



 Mar 25 2014



prev sibling next sibling parent  "Asman01" <jckj33 gmail.com>  writes:


On Tuesday, 25 March 2014 at 13:15:17 UTC, Timon Gehr wrote:

 On 03/25/2014 02:08 PM, bearophile wrote:

 Steve Teale:


 The only place I have tended to use the comma operator is in 
 ternary
 expressions

 bool universal;

 atq = whatever? 0: universal = true, 42;


 I classify that as quite tricky code, it's a negative example 
 :-(

 Bye,
 bearophile


 It's not tricky code. It is not even valid code. Operator 
 precedence from lowest to highest: , = ?.


Even ternary operator itself isn't allowed in a lot of 
programming team.



 Mar 25 2014



prev sibling  parent  "Steve Teale" <steve.teale britseyeview.com>  writes:


On Tuesday, 25 March 2014 at 13:15:17 UTC, Timon Gehr wrote:

 On 03/25/2014 02:08 PM, bearophile wrote:

 Steve Teale:


 The only place I have tended to use the comma operator is in 
 ternary
 expressions

 bool universal;

 atq = whatever? 0: universal = true, 42;


 I classify that as quite tricky code, it's a negative example 
 :-(

 Bye,
 bearophile


 It's not tricky code. It is not even valid code. Operator 
 precedence from lowest to highest: , = ?.


Yes, I most likely used

atq = whatever? 0: (universal = true, 42);



 Mar 26 2014



prev sibling  parent  "Steve Teale" <steve.teale britseyeview.com>  writes:


On Tuesday, 25 March 2014 at 13:08:59 UTC, bearophile wrote:

 Steve Teale:



 I classify that as quite tricky code, it's a negative example 
 :-(

 Bye,
 bearophile


I was not recommending it, I was just trying to think of when I'd 
used comma, and that popped into my head.

Basically I agree that it is likely to introduce errors (like 
mine in my example perhaps ;=), though in that case the compiler 
catches it.)

I could certainly live without it

Steve



 Mar 26 2014



prev sibling  parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Tuesday, 25 March 2014 at 12:43:07 UTC, Steve Teale wrote:

 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;

 R


 I presume that

 for (int i = 0, j = m;;) {}

 Is in the same category?


Yes, that's a declaration list, not a comma operator.



 Mar 25 2014



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


If you are not ready to break the code for it, there is nothing 
to discuss. It is not something to compromise about - either kill 
it completely, or just let it be. Anything else will make things 
only worse.



 Mar 24 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 24 March 2014 at 13:12:36 UTC, Dicebot wrote:

 If you are not ready to break the code for it, there is nothing 
 to discuss. It is not something to compromise about - either 
 kill it completely, or just let it be. Anything else will make 
 things only worse.


And yes, no one so far has presented a code case where using 
comma expression is legitimate and not just trying to save few 
keystrokes by confusing the hell out of everyone else.



 Mar 24 2014



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Mon, Mar 24, 2014 at 01:13:51PM +0000, Dicebot wrote:

 On Monday, 24 March 2014 at 13:12:36 UTC, Dicebot wrote:

If you are not ready to break the code for it, there is nothing to
discuss. It is not something to compromise about - either kill it
completely, or just let it be. Anything else will make things only
worse.


 
 And yes, no one so far has presented a code case where using comma
 expression is legitimate and not just trying to save few keystrokes by
 confusing the hell out of everyone else.


I vote to kill the comma operator.

The only actual legit use case I've seen so far is inside a for-loop,
where IMO the syntax should just be special-cased. All other uses
brought up so far fail to convince me about their merit -- they can all
be rewritten in a style that's more readable, less error-prone, and more
maintainable.  The objections all amount to "Oh no! You mean I have to
actually type 2 extra brace characters to write code in the bad style
I'm habitually used to writing?!", and "Oh no! I have to actually split
up my multiple statements into actual multiple statements which is
actually more readable for the poor sods who will have to maintain this
code after I leave?!", both which utterly fail to convince me.

The only "indispensible" use of the comma operator that I've seen in my
entire career is in IOCCC entries, where the whole point is to make the
code obscure and non-obvious.

Not to mention, the fact that some people have been asking about whether
"int x,y" will continue to be valid syntax shows that very few people
even understand what the comma operator *is*, much less its subtle
semantics, which is another strong sign that we should kill it with
extreme prejudice. Of all the bad design decisions made in C and C++,
the comma operator must be the most blatant one that D failed to shed.
Kill it, I say.


T

-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like. Otherwise the
programs they write will be pretty weird. -- D. Knuth



 Mar 24 2014



prev sibling next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 24 March 2014 at 13:12:36 UTC, Dicebot wrote:

 It is not something to compromise about - either kill it 
 completely, or just let it be. Anything else will make things 
 only worse.


Indeed.



 Mar 24 2014



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 24 March 2014 at 13:12:36 UTC, Dicebot wrote:

 If you are not ready to break the code for it, there is nothing 
 to discuss. It is not something to compromise about - either 
 kill it completely, or just let it be. Anything else will make 
 things only worse.


Actually, Andrei's solution of not being able to use the result 
is really nice as it allows to redefine the meaning later, as 
well as it limits the breakage.



 Mar 24 2014



prev sibling next sibling parent  "Sarath Kodali" <sarath dummy.com>  writes:


On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


The extensive use of binary comma operator that I had seen was in 
ctrace code.  
(http://docs.oracle.com/cd/E24457_01/html/E22003/ctrace.1.html). 
ctrace takes C code and inserts printfs for each statement so 
that the flow and variables' value can be observed during its 
execution.

For example,

while ((c = getchar()) != EOF)

is written as

while ( ((c = getchar()), printf(fmt, c), c) != EOF)

- Sarath



 Mar 24 2014



prev sibling next sibling parent  "Kagamin" <spam here.lot>  writes:


On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


I like comma operator and use often in my code, it's a very nice 
syntactic construct for mini-statements.

if(len<=optlen)opti=i, optj=j, optlen=len;



 Mar 24 2014



prev sibling next sibling parent  "Sean Kelly" <sean invisibleduck.org>  writes:


On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399


Kill it.  I'll admit to using the comma operator on occasion, but
never for any reason that warranted it.  If there are any
lingering uses in Druntime I'm 100% for eliminating them.



 Mar 24 2014



prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


I just introduced one in my own code:

if (s[0] != '/', s)



 Mar 25 2014



  parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Tuesday, 25 March 2014 at 11:54:25 UTC, Daniel Murphy wrote:

 I just introduced one in my own code:

 if (s[0] != '/', s)


What is it supposed to do? Do you want to check that s is at 
least 1 character long? Otherwise it's a NOP, AFAICS.



 Mar 25 2014



 next sibling parent  "Asman01" <jckj33 gmail.com>  writes:


On Tuesday, 25 March 2014 at 15:14:09 UTC, Marc Schütz wrote:

 On Tuesday, 25 March 2014 at 11:54:25 UTC, Daniel Murphy wrote:

 I just introduced one in my own code:

 if (s[0] != '/', s)


 What is it supposed to do? Do you want to check that s is at 
 least 1 character long? Otherwise it's a NOP, AFAICS.


I think it's supposed to test if first byte at s isn't '/' 
character ,s was a typo. I don't think it's a NOP because if I'm 
right, s is evaluated to begging of its address and it's always 
!= 0. So, if it will always run.



 Mar 25 2014



prev sibling  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Marc Schütz" " wrote in message 
news:ljmioogmqpvipifrhsub forum.dlang.org...


 What is it supposed to do? Do you want to check that s is at least 1 
 character long? Otherwise it's a NOP, AFAICS.


It was supposed to check if the first character was not '/', but for some 
reason it was always taking the if branch.

A similar one is
while (x);
    doSomething();

Which is nearly impossible to see, and I do all the time by accident. 
Thankfully the compiler catches that one for us. 



 Mar 25 2014



  parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Tuesday, 25 March 2014 at 16:14:27 UTC, Daniel Murphy wrote:

 "Marc Schütz" " wrote in message 
 news:ljmioogmqpvipifrhsub forum.dlang.org...


 What is it supposed to do? Do you want to check that s is at 
 least 1 character long? Otherwise it's a NOP, AFAICS.


 It was supposed to check if the first character was not '/', 
 but for some reason it was always taking the if branch.


Ok, so it was another argument against ",". I thought you were 
showing a new use-case, that's why I was confused...



 Mar 25 2014



prev sibling  parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru>  writes:


On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu 
wrote:

 Discuss: https://github.com/D-Programming-Language/dmd/pull/3399

 Andrei


+1

The comma operator is one of the most terrible things in C/C++.

Please, remove it from D.


use comma for multidimensional array definition. It will de nice 
to have the same multidimensional array support in D.



 Mar 25 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


ilya-stromberg:


 It will de nice to have the same multidimensional array support 
 in D.


In D it's much better to define them in library code.

Bye,
bearophile



 Mar 25 2014



  parent  "ilya-stromberg" <ilya-stromberg-2009 yandex.ru>  writes:


On Tuesday, 25 March 2014 at 15:35:01 UTC, bearophile wrote:

 ilya-stromberg:


 It will de nice to have the same multidimensional array 
 support in D.


 In D it's much better to define them in library code.

 Bye,
 bearophile


May be you are right and in D world we should define 
multidimensional arrays in library code. I just want to say that 




 Mar 25 2014