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 "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
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 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 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? 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
prev sibling 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 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
prev sibling 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 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 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 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
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 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
parent 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
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
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 next sibling parent 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
prev sibling next sibling 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 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
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 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 next sibling parent 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
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 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
prev sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--001a1134d616f17ef004f550241f
Content-Type: text/plain; charset=UTF-8

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 --001a1134d616f17ef004f550241f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>2014-03-24 10:09 GMT+09:00 bearophile <span dir=3D"lt= r">&lt;<a href=3D"mailto:bearophileHUGS lycos.com" target=3D"_blank">bearop= hileHUGS lycos.com</a>&gt;</span>:<br></div><div class=3D"gmail_extra"><div= class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=3D""=
Andrei Alexandrescu:<br>

<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Discuss: <a href=3D"https://github.com/D-Programming-Language/dmd/pull/3399= " target=3D"_blank">https://github.com/D-<u></u>Programming-Language/dmd/pu= ll/<u></u>3399</a><br> </blockquote> <br></div>Regarding the &quot;progress&quot;, I&#39;d like a good built-in = syntax to unpack tuples in assignments, inside function signatures, in fore= ach statements, and more, because the syntactic contortions I currently ado= pt to use tuples in D are bad.<br> </blockquote><div><br></div><div>I&#39;m partially against to it.</div><div=
<br></div><div>1.=C2=A0I think removing comma operator does not have usefu=


, we should resolve one-element tuple ambiguity=C2=A0first.</div><div>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(exp) =C2=A0 // one-element tuple, or just a= n expression ?</div><div>=C2=A0 =C2=A0 =C2=A0 And,=C2=A0 removing comma ope= rator=C2=A0does not=C2=A0resolve this issue.</div> <div><br></div><div>=C2=A0 =C2=A01b. If you choose other syntax for tuple, = comma operator will be no longer related to tuple syntax discussion.</div><= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {exp, exp2} =C2=A0// eg. using brace for tu= ple syntax no longer touch to comma operator</div> <div><br></div><div>2. Indeed in some case comma operator is bug-prone, but= if it is used directly on the ExpStatement, it&#39;s still useful to me.</= div><div><br></div><div>=C2=A0 =C2=A0 foreach (e; exp1, exp2) {} =C2=A0 // = maybe bug?</div> <div>=C2=A0 =C2=A0 if (cond) exp1, exp2; =C2=A0 // in most case, this is no= t a bug.</div><div><br></div><div>=C2=A0 =C2=A0So, completely removing comm= a operator will cause negative affect in some cases.</div><div><br></div><d= iv>Kenji Hara</div></div> </div></div> --001a1134d616f17ef004f550241f--
Mar 23 2014
prev sibling next sibling parent "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
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 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--001a1134d6162c6c3204f550e340
Content-Type: text/plain; charset=UTF-8

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 --001a1134d6162c6c3204f550e340 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2014= -03-24 10:38 GMT+09:00 Daniel Murphy <span dir=3D"ltr">&lt;<a href=3D"mailt= o:yebbliesnospam gmail.com" target=3D"_blank">yebbliesnospam gmail.com</a>&= gt;</span>:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">&quot;Kenji Hara&quot; &lt;<a href=3D"mailto= :k.hara.pg gmail.com" target=3D"_blank">k.hara.pg gmail.com</a>&gt; wrote i= n message news:mailman.27.1395624482.<u></u>25518.digitalmars-d puremagic.<= u></u>com...<div class=3D""> <br> 2014-03-24 10:09 GMT+09:00 bearophile &lt;<a href=3D"mailto:bearophileHUGS = lycos.com" target=3D"_blank">bearophileHUGS lycos.com</a>&gt;:<br> <br> </div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =C2=A0 =C2=A0 if (cond) exp1, exp2; =C2=A0 // in most case, this is not a b= ug.<br> </blockquote> <br></div> It&#39;s not a bug, but this does the same thing - so why use the comma ope= rator?<br> <br> if (cond) { exp1; exp2; }<br> <br> It catches bugs that are otherwise very difficult to spot. <br> </blockquote></div><br></div><div class=3D"gmail_extra"><div class=3D"gmail= _extra">At least I can imagine two reasonable cases.</div><div class=3D"gma= il_extra"><br></div><div class=3D"gmail_extra">1. If the code is ported fro= m C/C++, breaking it is not reasonable.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2. If the t= wo expressions are strongly related, using comma operator is reasonable to = represent the intensity.=C2=A0I think rather it&#39;s an *ability* to repre= sent code meaning by using code style.</div> <div><br></div><div>Kenji Hara</div></div></div> --001a1134d6162c6c3204f550e340--
Mar 23 2014
prev sibling next sibling parent "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
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 "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 next sibling 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:
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 "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 "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
prev sibling next sibling parent "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
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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
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
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 next 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling 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 next 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 "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
parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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.)

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
prev sibling next 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 "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
prev sibling next sibling 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 next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next 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 "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



 (



... ) 3
 (



... ) (3, ) I see this kind of confusion happen often, and the convenient syntax becomes a burden.
Mar 24 2014
prev sibling next 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 "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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



 (



... ) 3
 (



... ) (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 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 "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 next sibling 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, 2,]



 [1, 2, 3,]



Bye, bearophile
Mar 24 2014
prev sibling next sibling parent "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
prev sibling next sibling 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 "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 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 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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 :-) Similar code is possible in F#, OCaml, Scala, etc. Bye, bearophile
Mar 24 2014
prev sibling next sibling parent "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
prev sibling next sibling 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 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 next 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 "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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling 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 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 "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 "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 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
next sibling 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
parent "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
prev sibling 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 "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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling 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 next sibling parent "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
prev sibling next sibling 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 "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 "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 next sibling parent "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. P.S. C# also haven't got support of comma operator. Instead, it use comma for multidimensional array definition. It will de nice to have the same multidimensional array support in D.
Mar 25 2014
prev sibling next sibling parent "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
prev sibling next sibling 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 C# has great syntax for multidimensional arrays.
Mar 25 2014
prev sibling next sibling parent "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 :-)

 Similar code is possible in F#, OCaml, Scala, etc.

And in Rust: fn first((value, _): (int, f64)) -> int { value } Bye, bearophile
Mar 25 2014
prev sibling next sibling 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 next 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 next 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 "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