On Mon, Nov 16, 2009 at 2:04 PM, Justin Johansson <n...@spam.com> wrote: > Mentioned in the switch case statements thread, this probably should be a > separate discussion thread. > > Is the comma operator "another piece of C cruft" that needs to be removed > from D(2)? > > > grauzone wrote: >> Justin Johansson wrote: >>> bearophile wrote: >>>> What's bad about forcing people to write: >>>> case A, B, C: >>>> >>>> Instead of: >>>> case A: >>>> case B: >>>> case C: >>>> ? >>>> >>>> Bye, >>>> bearophile >>> >>> I don't know about "forcing people" to write such but perhaps it could >>> be an "option for people" :-) >>> >>> Actually I quite like the brevity you propose but would it be a >>> challenge for the comma operator? >>> >>> While ago, I got D multi-dimensional array syntax messed up and >>> declared such an animal as >>> int[3,4,5] which effectively ended up declaring the beast as int[5]. >> >> The comma operator is another piece of C cruft that needs to go.
Note that if comma-as-sequencer was removed, and repurposed as a tuple literal (with "a,b" making a tuple), and if we specify that tuple elements are evaluated in order, then I think this would work as a replacement for the current comma operator: (expr1,expr2,expr3)[$-1] But the nice thing is you can get the effect of a comma operator that evaluates to the value of any expression in the sequence, just using different indices. Not sure how odious people would find forcing an order of eval on tuples, though. In the context of a for-loop, you don't care what the value is, so it would work as a tuple as-is. The tuple itself would be the value: for(; i<10; ++i,++j) // just works Though, probably this case needs some special treatment to continue working: int i=0,j=0 --bb