www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Comma operator = broken design

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
Hi,

Consider this code:

if (condition)
     foo();
else
     bar(),

baz();

Notice the comma in the bar call. This will actually compile. Why? 
Because the program is really interpreted as:

if (condition)
{
     foo();
}
else
{
     bar();
     baz();
}

This is, honestly, ridiculous. On most European keyboard layouts, comma 
is on the same key as semicolon. This means that a typo such as the 
above can lead to an incorrect (but compiling) program easily, rather 
than a compile-time error.

I really do not see the value in allowing such syntax in the first 
place. I've been told that one argument was that generated code might 
use it, but I have no idea why it would be needed. Furthermore, this 
operator makes it very hard to introduce Python-style tuples in the 
language.

Why is this operator still kept around?

- Alex
Dec 07 2011
next sibling parent "Joshua Cearley" <joshua.cearley gmail.com> writes:
It could be moved to use either the section character or one of the
application-specific unicode points reserved for internal use by whatever an
application wants.  This would eliminate confusing typing and, if using this
for generated code, the generator can easily reference it by unicode ID when
constructing the strings.
Dec 07 2011
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen <xtzgzorex gmail.com>
wrote:
 Hi,

 Consider this code:

 if (condition)
      foo();
 else
      bar(),

 baz();

 Notice the comma in the bar call. This will actually compile. Why?
 Because the program is really interpreted as:

 if (condition)
 {
      foo();
 }
 else
 {
      bar();
      baz();
 }

 This is, honestly, ridiculous. On most European keyboard layouts, comma
 is on the same key as semicolon. This means that a typo such as the
 above can lead to an incorrect (but compiling) program easily, rather
 than a compile-time error.

 I really do not see the value in allowing such syntax in the first
 place. I've been told that one argument was that generated code might
 use it, but I have no idea why it would be needed. Furthermore, this
 operator makes it very hard to introduce Python-style tuples in the
 language.

 Why is this operator still kept around?

Take your pick: 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2. 2) The comma operator is heavily used in regular old for loops. 3) It is frequently used internally by the compiler to effect syntactic lowerings. A decent portion of D's syntax is not transformed directly to instructions; instead it is converted to simpler code which is in turn processed. Technically the compiler doesn't need ',' in the language to do this. 4) D has a policy of 'If C/C++ code compiles in D without error, it must have the same syntactic meaning as in C.' So even if we remove the comma operator, we might not get comma-style tuples. (I don't know if anyone has looked at this issue in depth) 5) The comma and semicolon are on different keys on US style keyboards. 6) It is trivial to change your keyboard layout (I've hotkeyed Greek for fast math symbols) 7) We are trying to stabilize the language, so massive code-breaks are frowned upon. Personally, I think real tuples outweigh the comma-operator, but real tuples don't necessarily need the ',' (we could use '..' or something else instead) and removing comma-expressions isn't without its problems. P.S. I was going to suggest testing/looking into issue 4, but a quick test in D suggests that there are valid ',' and '(,)' style expressions in C/C++ that would remain valid in D with comma-tuples.
Dec 07 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Robert Jacques" <sandford jhu.edu> wrote in message 
news:op.v54q04vd26stm6 sandford.myhome.westell.com...
 On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen 
 <xtzgzorex gmail.com> wrote:
 Why is this operator still kept around?

Take your pick: 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2.

That's a pretty weak counter-argument: A. I'd think a lot of C/C++ code can't be trivially ported to D anyway. B. "B", seriously? ;) C. Being able to link to C/C++ makes it less likely to need to port C/C++ code anyway. D. Outside of for loops (special-case-able), comma operator is rarely used in C/C++/D. E. Even among actual uses of the comma operator, I think it'd be rare (if even possible) to have a use of it that isn't trivially convertable to non-comma.
 2) The comma operator is heavily used in regular old for loops.

That can be special cased.
 3) It is frequently used internally by the compiler to effect syntactic 
 lowerings. A decent portion of D's syntax is not transformed directly to 
 instructions; instead it is converted to simpler code which is in turn 
 processed. Technically the compiler doesn't need ',' in the language to do 
 this.

Like you're saying, it can exist in the compiler's internal AST without having to exist in the parser.
 4) D has a policy of 'If C/C++ code compiles in D without error, it must 
 have the same syntactic meaning as in C.' So even if we remove the comma 
 operator, we might not get comma-style tuples. (I don't know if anyone has 
 looked at this issue in depth)

Meh, I still think it would be better to allow such situations on occasion and just provide a "--c-lint" switch to warn (or error) on any such code. Porting C/C++ to D is a much smaller use case than writing/maintaining D. I don't think it's a good idea to hamper the langauge for the sake of such an edge case when it's just as possible to simply handle that scenario with a special tool/switch. But I guess I'm outvoted by Walter on that :(
 5) The comma and semicolon are on different keys on US style keyboards.
 6) It is trivial to change your keyboard layout (I've hotkeyed Greek for 
 fast math symbols)

Those are very weak counter-arguments.
 7) We are trying to stabilize the language, so massive code-breaks are 
 frowned upon.

Poo ;(
 Personally, I think real tuples outweigh the comma-operator, but real 
 tuples don't necessarily need the ',' (we could use '..' or something else 
 instead) and removing comma-expressions isn't without its problems.

 P.S. I was going to suggest testing/looking into issue 4, but a quick test 
 in D suggests that there are valid ',' and '(,)' style expressions in 
 C/C++ that would remain valid in D with comma-tuples. 

Dec 07 2011
parent Joshua Reusch <yoschi arkandos.de> writes:
 Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
 for loop, where it is used to separate two statements?

If we use the comma operator only for tuples, there needn't to be a special case for loops: for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }
Dec 08 2011
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Alex Rønne Petersen Wrote:
 I really do not see the value in allowing such syntax in the first 
 place. I've been told that one argument was that generated code might 
 use it, but I have no idea why it would be needed.

Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently. I have a thing that takes an attribute and pastes it into a code string to check it. given validate="this.value.length > 3" it writes: if(!(this.value.length > 3)) return false; // failed validation since the given string is inside an if statement, you can't put a semicolon in there. So, if you have a check more complex than returning a boolean and want to stuff it all in that string (so functions are out), the comma lets you do it: validate="do something, true" This is pretty ugly style that I think I've only ever done in D inside a for loop... but the point is sometimes something comes up, and it's nice to have another option available, even if it is ugly.
Dec 07 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam Ruppe" <destructionator gmail.com> wrote in message 
news:jbo8rr$rhh$1 digitalmars.com...
 Alex Rønne Petersen Wrote:
 I really do not see the value in allowing such syntax in the first
 place. I've been told that one argument was that generated code might
 use it, but I have no idea why it would be needed.

Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently. I have a thing that takes an attribute and pastes it into a code string to check it. given validate="this.value.length > 3" it writes: if(!(this.value.length > 3)) return false; // failed validation since the given string is inside an if statement, you can't put a semicolon in there. So, if you have a check more complex than returning a boolean and want to stuff it all in that string (so functions are out), the comma lets you do it: validate="do something, true" This is pretty ugly style that I think I've only ever done in D inside a for loop... but the point is sometimes something comes up, and it's nice to have another option available, even if it is ugly.

Don't know about JS, but D can solve the same problem with anon delegates, which is less obscure anyway.
Dec 07 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/07/2011 07:02 PM, Nick Sabalausky wrote:
 "Adam Ruppe"<destructionator gmail.com>  wrote in message
 news:jbo8rr$rhh$1 digitalmars.com...
 Alex Rønne Petersen Wrote:
 I really do not see the value in allowing such syntax in the first
 place. I've been told that one argument was that generated code might
 use it, but I have no idea why it would be needed.

Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently. I have a thing that takes an attribute and pastes it into a code string to check it. given validate="this.value.length> 3" it writes: if(!(this.value.length> 3)) return false; // failed validation since the given string is inside an if statement, you can't put a semicolon in there. So, if you have a check more complex than returning a boolean and want to stuff it all in that string (so functions are out), the comma lets you do it: validate="do something, true" This is pretty ugly style that I think I've only ever done in D inside a for loop... but the point is sometimes something comes up, and it's nice to have another option available, even if it is ugly.

Don't know about JS, but D can solve the same problem with anon delegates, which is less obscure anyway.

I think Don said that DMD cannot currently inline any delegates. Imho the spec should even *require* inlining in the special case that such a delegate is immediately executed. (even for debug builds).
Dec 07 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, December 07, 2011 23:10:53 Timon Gehr wrote:
 On 12/07/2011 07:02 PM, Nick Sabalausky wrote:
 "Adam Ruppe"<destructionator gmail.com> wrote in message
 news:jbo8rr$rhh$1 digitalmars.com...
 
 Alex Rønne Petersen Wrote:
 I really do not see the value in allowing such syntax in the first
 place. I've been told that one argument was that generated code
 might
 use it, but I have no idea why it would be needed.

Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently. I have a thing that takes an attribute and pastes it into a code string to check it. given validate="this.value.length> 3" it writes: if(!(this.value.length> 3)) return false; // failed validation since the given string is inside an if statement, you can't put a semicolon in there. So, if you have a check more complex than returning a boolean and want to stuff it all in that string (so functions are out), the comma lets you do it: validate="do something, true" This is pretty ugly style that I think I've only ever done in D inside a for loop... but the point is sometimes something comes up, and it's nice to have another option available, even if it is ugly.

Don't know about JS, but D can solve the same problem with anon delegates, which is less obscure anyway.

I think Don said that DMD cannot currently inline any delegates. Imho the spec should even *require* inlining in the special case that such a delegate is immediately executed. (even for debug builds).

lazy doesn't get inlined for the same reason (since it's essentially using a delegate), and that potentially has some nasty implications for performance with regards to stuff like enforce. In the recent thread on std.regex's performance, while enforce was definitely not at the top of the list of functions in the profiler (listed descending by running time), it was definitely a decent portion of the running time of the program. The cost of enforce should be comparable to the cost of assert, but with the issues of inlining lazy and delegates, it definitely isn't that efficient. These sorts of things need to be inlinable. - Jonathan M Davis
Dec 07 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 07 Dec 2011 13:19:31 -0500, Nick Sabalausky <a a.a> wrote:

 "Robert Jacques" <sandford jhu.edu> wrote in message
 news:op.v54q04vd26stm6 sandford.myhome.westell.com...
 On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen
 <xtzgzorex gmail.com> wrote:
 Why is this operator still kept around?

Take your pick: 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2.

That's a pretty weak counter-argument: A. I'd think a lot of C/C++ code can't be trivially ported to D anyway.

 B. "B", seriously? ;)

 C. Being able to link to C/C++ makes it less likely to need to port C/C++
 code anyway.

 D. Outside of for loops (special-case-able), comma operator is rarely used
 in C/C++/D.

 E. Even among actual uses of the comma operator, I think it'd be rare (if
 even possible) to have a use of it that isn't trivially convertable to
 non-comma.

 2) The comma operator is heavily used in regular old for loops.

That can be special cased.

 5) The comma and semicolon are on different keys on US style keyboards.
 6) It is trivial to change your keyboard layout (I've hotkeyed Greek for
 fast math symbols)

Those are very weak counter-arguments.

Dec 07 2011
prev sibling next sibling parent reply bcs <bcs example.com> writes:
On 12/07/2011 08:49 AM, Alex Rønne Petersen wrote:
 I really do not see the value in allowing such syntax in the first
 place. I've been told that one argument was that generated code might
 use it, but I have no idea why it would be needed. Furthermore, this
 operator makes it very hard to introduce Python-style tuples in the
 language.

IIRC the generated code argument was actually made with regards to the compiler doing internal rewriting of the AST. If I'm remembering correctly, this make it even weaker as, at that point, there is no reason that the form of the AST need match the syntax.
Dec 07 2011
parent Don <nospam nospam.com> writes:
On 08.12.2011 05:52, bcs wrote:
 On 12/07/2011 08:49 AM, Alex Rønne Petersen wrote:
 I really do not see the value in allowing such syntax in the first
 place. I've been told that one argument was that generated code might
 use it, but I have no idea why it would be needed. Furthermore, this
 operator makes it very hard to introduce Python-style tuples in the
 language.

IIRC the generated code argument was actually made with regards to the compiler doing internal rewriting of the AST. If I'm remembering correctly, this make it even weaker as, at that point, there is no reason that the form of the AST need match the syntax.

Worth noting that the comma operator inside the compiler is not the same as the one in the language. It supports declarations, in a way that D doesn't. You can't write this in normal D, for example: (int x; , x = 2); But that's what the compiler does internally. The "compiler uses it internally" argument isn't valid at all.
Dec 08 2011
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
 
 Why is this operator still kept around?

No offense, but I find it strange/funny that you even ask why! :) Have you never used comma in for loops???
Dec 08 2011
next sibling parent reply so <so so.so> writes:
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic <dejan.lekic gmail.com>  
wrote:

 Why is this operator still kept around?

No offense, but I find it strange/funny that you even ask why! :) Have you never used comma in for loops???

Not sure if it is that relevant for D, but good point. for(auto i=beg(), e=end(); i!=e; ++i) for(auto i, j, k;; ++i, ++k) ...
Dec 08 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/08/2011 05:02 PM, Regan Heath wrote:
 On Thu, 08 Dec 2011 12:17:20 -0000, so <so so.so> wrote:

 On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
 <dejan.lekic gmail.com> wrote:

 Why is this operator still kept around?

No offense, but I find it strange/funny that you even ask why! :) Have you never used comma in for loops???

Not sure if it is that relevant for D, but good point. for(auto i=beg(), e=end(); i!=e; ++i) for(auto i, j, k;; ++i, ++k) ...

It's kinda amusing that this thread appeared just as we had a case of this here at work. The developer accidentally coded something like... if (function(..), FALSE) { } Accidentally adding the ", FALSE" /after/ the ) instead of as a new parameter to the function. (note; This was in C++ with default parameter values so the function can in fact take 1-4 args). When I pointed this out, he said "how does that even compile" and was completely unaware of the existence of the comma operator, nor (once I explained it) did he realise it was in any way related to the comma used in for loops. People simply don't think of them as being the same thing at all. Instead, people learn the comma syntax as a special characteristic of the for loop, and use it nowhere else. I think the comma operator is of little benefit (except where used in a for loop) and it is a source of bugs and we'd be better off without it. Even if it means porting C/C++ requires modification, or existing D (I doubt very much of it) breaks.

Phobos would break, for example. And some of my code too.
Dec 08 2011
next sibling parent reply Don <nospam nospam.com> writes:
On 08.12.2011 20:22, Timon Gehr wrote:
 On 12/08/2011 05:02 PM, Regan Heath wrote:
 On Thu, 08 Dec 2011 12:17:20 -0000, so <so so.so> wrote:

 On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
 <dejan.lekic gmail.com> wrote:

 Why is this operator still kept around?

No offense, but I find it strange/funny that you even ask why! :) Have you never used comma in for loops???

Not sure if it is that relevant for D, but good point. for(auto i=beg(), e=end(); i!=e; ++i) for(auto i, j, k;; ++i, ++k) ...

It's kinda amusing that this thread appeared just as we had a case of this here at work. The developer accidentally coded something like... if (function(..), FALSE) { } Accidentally adding the ", FALSE" /after/ the ) instead of as a new parameter to the function. (note; This was in C++ with default parameter values so the function can in fact take 1-4 args). When I pointed this out, he said "how does that even compile" and was completely unaware of the existence of the comma operator, nor (once I explained it) did he realise it was in any way related to the comma used in for loops. People simply don't think of them as being the same thing at all. Instead, people learn the comma syntax as a special characteristic of the for loop, and use it nowhere else. I think the comma operator is of little benefit (except where used in a for loop) and it is a source of bugs and we'd be better off without it. Even if it means porting C/C++ requires modification, or existing D (I doubt very much of it) breaks.

Phobos would break, for example. And some of my code too.

Are there any cases where you're using comma outside of for loops? I wonder how much would break if were made illegal everywhere else.
Dec 09 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 10:19 AM, Don wrote:
 On 08.12.2011 20:22, Timon Gehr wrote:
 On 12/08/2011 05:02 PM, Regan Heath wrote:
 On Thu, 08 Dec 2011 12:17:20 -0000, so <so so.so> wrote:

 On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
 <dejan.lekic gmail.com> wrote:

 Why is this operator still kept around?

No offense, but I find it strange/funny that you even ask why! :) Have you never used comma in for loops???

Not sure if it is that relevant for D, but good point. for(auto i=beg(), e=end(); i!=e; ++i) for(auto i, j, k;; ++i, ++k) ...

It's kinda amusing that this thread appeared just as we had a case of this here at work. The developer accidentally coded something like... if (function(..), FALSE) { } Accidentally adding the ", FALSE" /after/ the ) instead of as a new parameter to the function. (note; This was in C++ with default parameter values so the function can in fact take 1-4 args). When I pointed this out, he said "how does that even compile" and was completely unaware of the existence of the comma operator, nor (once I explained it) did he realise it was in any way related to the comma used in for loops. People simply don't think of them as being the same thing at all. Instead, people learn the comma syntax as a special characteristic of the for loop, and use it nowhere else. I think the comma operator is of little benefit (except where used in a for loop) and it is a source of bugs and we'd be better off without it. Even if it means porting C/C++ requires modification, or existing D (I doubt very much of it) breaks.

Phobos would break, for example. And some of my code too.

Are there any cases where you're using comma outside of for loops?

Yes, one for every 65 LOC.
 I wonder how much would break if were made illegal everywhere else.

These are the occurences of the comma operator in directory 'std': return r2.empty ? (r1 = r, true) : false; return binaryFun!pred(r.front, e) ? (r.popFront(), true) : false; if (f.flPlus) signChar = '+', ++minw; else if (f.flSpace) signChar = ' ', ++minw; if (std.ascii.toLower(p.front) == 'n' && (p.popFront(), std.ascii.toLower(p.front) == 'f') && (p.popFront(), p.empty)) enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A') && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'), new ConvException("error converting input to floating point")); if (indexStart != 0) formatValue(w, indexStart, f), put(w, '$'); if (c == '\"' || c == '\\') put(w, '\\'), put(w, c); else put(w, c); return (++mi.m_cRefs, cast(HXModule)mi); return (++mi.m_cRefs, hModule); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : (assert(false), 6);
Dec 09 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:

 These are the occurences of the comma operator in directory 'std':
 
 return r2.empty ? (r1 = r, true) : false;
 return binaryFun!pred(r.front, e) ? (r.popFront(), true) : false;
 
 if (f.flPlus)
      signChar = '+', ++minw;
 else if (f.flSpace)
      signChar = ' ', ++minw;
 
 if (std.ascii.toLower(p.front) == 'n' &&
         (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
         (p.popFront(), p.empty))
 
 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
          && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
         new ConvException("error converting input to floating point"));
 
 if (indexStart != 0)
      formatValue(w, indexStart, f), put(w, '$');
 
 if (c == '\"' || c == '\\')
      put(w, '\\'), put(w, c);
 else
      put(w, c);
 
 return (++mi.m_cRefs, cast(HXModule)mi);
 return (++mi.m_cRefs, hModule);
 
 return
      c <= 0x7F ? 1
      : c <= 0x7FF ? 2
      : c <= 0xFFFF ? 3
      : c <= 0x10FFFF ? 4
      : (assert(false), 6);

It's ugly code worth fixing/rewriting. If I see something like that in production code, I always burn it with fire and rewrite it. Turning such usages of comma operator into syntax errors looks like a general improvement for D. Bye, bearophile
Dec 09 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 01:36 PM, Regan Heath wrote:
 4)

 if (std.ascii.toLower(p.front) == 'n' &&
 (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
 (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling

Your '//error handling' shortcut hides relevant information.
 5)

 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
 && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
 new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point"));

This is blatant code duplication.
 7)

 if (c == '\"' || c == '\\')
 put(w, '\\'), put(w, c);
 else
 put(w, c);

More {}; avoidance.. if (c == '\"' || c == '\\') { put(w, '\\'); put(w, c); } else { put(w, c); }

No comma operator necessary to avoid {}: if(x == '"' || c == '\\') put(w, '\\'); put(w, c);
 8)

 return (++mi.m_cRefs, cast(HXModule)mi);

less (), one more ; and <enter>.. ++mi.m_cRefs; return cast(HXModule)mi;

() would not be necessary.
 9)

 return (++mi.m_cRefs, hModule);

as above.. ++mi.m_cRefs; return hModule; 10)
 return
 c <= 0x7F ? 1
 : c <= 0x7FF ? 2
 : c <= 0xFFFF ? 3
 : c <= 0x10FFFF ? 4
 : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6;

This is a *much* better rewrite: assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : 4;
 None of the above look significantly harder without the comma operator
 and quite a few are far clearer (to me) without it.

Yah, many of those occurences in Phobos are mostly unnecessary.
Dec 09 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 02:28 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:15:47 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 01:36 PM, Regan Heath wrote:
 4)

 if (std.ascii.toLower(p.front) == 'n' &&
 (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
 (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling

Your '//error handling' shortcut hides relevant information.

What information? With context I could be more specific about what to do for each/all.

You can always grep the Phobos source to get context. Basically, you are suggesting to replace the comma operator with gotos: case 'i': case 'I': p.popFront(); if (std.ascii.toLower(p.front) == 'n' && (p.popFront(), std.ascii.toLower(p.front) == 'f') && (p.popFront(), p.empty)) { // 'inf' return sign ? -Target.infinity : Target.infinity; } goto default; default: {} }
 5)

 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
 && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
 new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point"));

This is blatant code duplication.

Of the throw line? Sure, and you can re-write with nested 'if' if you prefer. I prefer the code duplication tho.

Code duplication is very error prone. Furthermore I never ever want to duplicate _error handling_ code. That just clutters up the generated machine code if the compiler does not manage to reverse engineer and generate the proper solution.
 7)

 if (c == '\"' || c == '\\')
 put(w, '\\'), put(w, c);
 else
 put(w, c);

More {}; avoidance.. if (c == '\"' || c == '\\') { put(w, '\\'); put(w, c); } else { put(w, c); }

No comma operator necessary to avoid {}: if(x == '"' || c == '\\') put(w, '\\'); put(w, c);

Yeah, it was a /quick/ re-write without additional re-factoring (aside from removal of the comma).
 8)

 return (++mi.m_cRefs, cast(HXModule)mi);

less (), one more ; and <enter>.. ++mi.m_cRefs; return cast(HXModule)mi;

() would not be necessary.

True, but if you're going to use the comma operator, enclosing it in () at makes it more obvious you've done so. I tend to use extra () when using the ?: operator for this reason.

You sort of made it look like the comma operator solution was more verbose. ;)
 9)

 return (++mi.m_cRefs, hModule);

as above.. ++mi.m_cRefs; return hModule; 10)
 return
 c <= 0x7F ? 1
 : c <= 0x7FF ? 2
 : c <= 0xFFFF ? 3
 : c <= 0x10FFFF ? 4
 : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6;

This is a *much* better rewrite: assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : 4;

Again, I was missing context.. is the return value of 6 not required in release mode?

I was joking here. Your 'rewrite' of the original example changed its release mode semantics, therefore I did the same thing.
 None of the above look significantly harder without the comma operator
 and quite a few are far clearer (to me) without it.

Yah, many of those occurences in Phobos are mostly unnecessary.

:)

Dec 09 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 03:25 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:42:34 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 02:28 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:15:47 -0000, Timon Gehr <timon.gehr gmx.ch>
 wrote:
 On 12/09/2011 01:36 PM, Regan Heath wrote:
 4)

 if (std.ascii.toLower(p.front) == 'n' &&
 (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
 (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling

Your '//error handling' shortcut hides relevant information.

What information? With context I could be more specific about what to do for each/all.

You can always grep the Phobos source to get context. Basically, you are suggesting to replace the comma operator with gotos: case 'i': case 'I': p.popFront(); if (std.ascii.toLower(p.front) == 'n' && (p.popFront(), std.ascii.toLower(p.front) == 'f') && (p.popFront(), p.empty)) { // 'inf' return sign ? -Target.infinity : Target.infinity; } goto default; default: {} }

If using 'goto' is the 'correct' agreed upon style for phobos then, yes. It's not my personal preference however and I'd probably refactor it further if it was my own code.
 5)

 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
 && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
 new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point"));

This is blatant code duplication.

Of the throw line? Sure, and you can re-write with nested 'if' if you prefer. I prefer the code duplication tho.

Code duplication is very error prone. Furthermore I never ever want to duplicate _error handling_ code. That just clutters up the generated machine code if the compiler does not manage to reverse engineer and generate the proper solution.

I can't comment on the machine code aspect. I don't find this particular duplication error prone, but if you do you can use the nested if that I've already mentioned.
 10)

 return
 c <= 0x7F ? 1
 : c <= 0x7FF ? 2
 : c <= 0xFFFF ? 3
 : c <= 0x10FFFF ? 4
 : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6;

This is a *much* better rewrite: assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : 4;

Again, I was missing context.. is the return value of 6 not required in release mode?

I was joking here. Your 'rewrite' of the original example changed its release mode semantics, therefore I did the same thing.

My version performs the assert in all cases, throws an assert error in the same/error cases, and still returns the correct/original values. The only change is performing the assert in all cases, so I don't see how that is a problem. Yours however is entirely broken (assuming the return value of 6 is desired/required). R

What you might be missing is that assert(false) is not compiled out in release mode. It emits a 'hlt' instruction which kills your program. However, your assert(c <= 0x10FFFF); will be removed in release mode.
Dec 09 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 04:37 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 14:54:16 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 10)

 return
 c <= 0x7F ? 1
 : c <= 0x7FF ? 2
 : c <= 0xFFFF ? 3
 : c <= 0x10FFFF ? 4
 : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6;

This is a *much* better rewrite: assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : 4;

Again, I was missing context.. is the return value of 6 not required in release mode?

I was joking here. Your 'rewrite' of the original example changed its release mode semantics, therefore I did the same thing.

My version performs the assert in all cases, throws an assert error in the same/error cases, and still returns the correct/original values. The only change is performing the assert in all cases, so I don't see how that is a problem. Yours however is entirely broken (assuming the return value of 6 is desired/required). R

What you might be missing is that assert(false) is not compiled out in release mode. It emits a 'hlt' instruction which kills your program. However, your assert(c <= 0x10FFFF); will be removed in release mode.

I was indeed missing that. I couldn't find anything about it on the website. :) R

http://d-programming-language.org/expression.html#AssertExpression
Dec 09 2011
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
I didn't notice the other parts of your post before.

On 12/09/2011 03:25 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:42:34 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 02:28 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:15:47 -0000, Timon Gehr <timon.gehr gmx.ch>
 wrote:
 On 12/09/2011 01:36 PM, Regan Heath wrote:
 4)

 if (std.ascii.toLower(p.front) == 'n' &&
 (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
 (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling

Your '//error handling' shortcut hides relevant information.

What information? With context I could be more specific about what to do for each/all.

You can always grep the Phobos source to get context. Basically, you are suggesting to replace the comma operator with gotos: case 'i': case 'I': p.popFront(); if (std.ascii.toLower(p.front) == 'n' && (p.popFront(), std.ascii.toLower(p.front) == 'f') && (p.popFront(), p.empty)) { // 'inf' return sign ? -Target.infinity : Target.infinity; } goto default; default: {} }

If using 'goto' is the 'correct' agreed upon style for phobos then, yes. It's not my personal preference however and I'd probably refactor it further if it was my own code.

The code was probably written that way to give an optimal implementation that does not use goto. How would you refactor the code?
 5)

 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
 && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
 new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point"));

This is blatant code duplication.

Of the throw line? Sure, and you can re-write with nested 'if' if you prefer. I prefer the code duplication tho.

Code duplication is very error prone. Furthermore I never ever want to duplicate _error handling_ code. That just clutters up the generated machine code if the compiler does not manage to reverse engineer and generate the proper solution.

I can't comment on the machine code aspect. I don't find this particular duplication error prone, but if you do you can use the nested if that I've already mentioned.

I don't like the nested if solution. Also it does not work that well in the general case because you might have a || operator somewhere instead of just && operators.
Dec 09 2011
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 01:56 PM, Derek wrote:
 On Fri, 09 Dec 2011 22:39:55 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:

 These are the occurences of the comma operator in directory 'std': ...

OMG! What ever happened to the idea that source code is meant to AID reading programs and not making it obscured. These are examples for a 'shame' file, or "how not to write useful code".

You are exaggerating. http://www.ioccc.org/
Dec 09 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 09, 2011 12:36:25 Regan Heath wrote:
 On Fri, 09 Dec 2011 11:39:55 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 These are the occurences of the comma operator in directory 'std':

each snippet. There may be much better re-writes in context. Re-writing this was problematic /because/ the comma operator makes things that much more confusing to me. Especially example #5 below where the last , actually separates enforce parameters! 1)
 return r2.empty ? (r1 = r, true) : false;

if (!r2.empty) return false; r1 = r; return true;

Actually, that particular usage of the comma operator makes me almost want to use it that way. It manages to take one of the type of statements that always irritates me when it's multiple lines and make it a single line. - Jonathan M Davis
Dec 09 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 On Friday, December 09, 2011 10:19:18 Don wrote:
 Are there any cases where you're using comma outside of for loops?
 I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops.

'most people'?
 Occasionally, it's
 useful to use one in an expression, but on the whole, it's just confusing and
 error-prone.

It is confusing to people who don't know the language. It is a simple construct. In my experience, it is certainly not error prone. If you are aware that such an operator exists.
 And while it might break code to make the comma operator illegal
 outside of for loops, I would expect that fixing the broken code would
 generally be rather trivial.

Sure.
 The resulting code may not be as compact, but it
 wouldn't be hard to write.

It would be a PITA in some cases.
 And unless you're dealing with a programmer who
 uses it uncommonly often, not much code is going to break.

I _am_ such a programmer.
Dec 09 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 01:11 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 12:00:57 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 On Friday, December 09, 2011 10:19:18 Don wrote:
 Are there any cases where you're using comma outside of for loops?
 I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops.

'most people'?

Yes, I would guess that you're in the minority here.

'most people' do not care about this discussion, so lets stop it. :o) What I wanted to say is just that throwing in 'most people' does not help an argument, because a) there is no evidence and b) 'most people' are in general just as often (or even more) wrong than 'a few people'.
 Occasionally, it's
 useful to use one in an expression, but on the whole, it's just
 confusing and
 error-prone.

It is confusing to people who don't know the language. It is a simple construct. In my experience, it is certainly not error prone. If you are aware that such an operator exists.

It's error prone in cases where you use it without realising, as in the example I posted.

That is true for every language construct.
 The resulting code may not be as compact, but it
 wouldn't be hard to write.

It would be a PITA in some cases.

Really? Give us an example where not having comma makes things significantly difficult.

I already agreed that rewriting the code is trivial. It is just that I usually do not want to spend lots of my time on trivial stuff.
 And unless you're dealing with a programmer who
 uses it uncommonly often, not much code is going to break.

I _am_ such a programmer.

So it seems :)

If you carefully read my posts you will find that I did never say that I am against removing the comma operator. I would like comma to have tuple semantics. Comma should keep its precedence level and then work like this: if(foo) bar, baz, qux; // the value of the tuple is unused, so no change in semantics if(bar()||(foo(), *++p==(*++x)++)[1]){} // the value is used, so an explicit index is necessary It would make the language more consistent because the comma in expressions would be the same comma as the one that is used elsewhere. That is against the C compatibility rule though, and it would in some cases silently break code.
 I don't want to make your life harder but I think this
 change would make life easier for a large number of people, a small
 amount of the time. The equation is unbalanced in favour of it's
 removal, IMO.

This part of your post is somewhat contradictory.
Dec 09 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 02:33 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:01:12 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 01:11 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 12:00:57 -0000, Timon Gehr <timon.gehr gmx.ch>
 wrote:
 On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 On Friday, December 09, 2011 10:19:18 Don wrote:
 Are there any cases where you're using comma outside of for loops?
 I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops.

'most people'?

Yes, I would guess that you're in the minority here.

'most people' do not care about this discussion, so lets stop it. :o)

Sure.
 So it seems :)

If you carefully read my posts you will find that I did never say that I am against removing the comma operator.

Excellent.
 I don't want to make your life harder but I think this
 change would make life easier for a large number of people, a small
 amount of the time. The equation is unbalanced in favour of it's
 removal, IMO.

This part of your post is somewhat contradictory.

How so? R

Removing the comma operator makes my life harder. You don't want to do so. You want to remove the comma operator. Conclusion: Today is Monday.
Dec 09 2011
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Regan Heath wrote:
 On Fri, 09 Dec 2011 12:00:57 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 And unless you're dealing with a programmer who
 uses it uncommonly often, not much code is going to break.

I _am_ such a programmer.

So it seems :) I don't want to make your life harder but I think this change would make life easier for a large number of people [...]

What about just not using comma operator? Yes, I know about keyboard issue. There are many cases when 'typoed' code compiles but doesn't work as programmer would expect. This is not limited to comma op. Some programmers do not like gotos, comma operator or other language constructs. Some like the opposites. I would suggest making a patch to the compiler to introduce a new pragma: pragma(disable, commaOp); and programmers will be able to place it in every source file they want to.
Dec 09 2011
prev sibling parent reply Tobias Pankrath <tobias pankrath.net> writes:
Timon Gehr wrote:

 It is confusing to people who don't know the language. It is a simple
 construct. In my experience, it is certainly not error prone. If you are
 aware that such an operator exists.

It may not be error prone to write, but it is error prone to read, because the comma-operator tends to hide in the language noise produced by all those brackets, semicolons, commas, parenthesis and curly braces. I don't like it, if I have to be uber careful when reading trivial code.
Dec 09 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/09/2011 02:38 PM, Tobias Pankrath wrote:
 Timon Gehr wrote:

 It is confusing to people who don't know the language. It is a simple
 construct. In my experience, it is certainly not error prone. If you are
 aware that such an operator exists.

It may not be error prone to write, but it is error prone to read, because the comma-operator tends to hide in the language noise produced by all those brackets, semicolons, commas, parenthesis and curly braces. I don't like it, if I have to be uber careful when reading trivial code.

You always have to be careful when reading code. I prefer when there is not a lot to read (dense code).
Dec 09 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 09, 2011 10:19:18 Don wrote:
 Are there any cases where you're using comma outside of for loops?
 I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops. Occasionally, it's useful to use one in an expression, but on the whole, it's just confusing and error-prone. And while it might break code to make the comma operator illegal outside of for loops, I would expect that fixing the broken code would generally be rather trivial. The resulting code may not be as compact, but it wouldn't be hard to write. And unless you're dealing with a programmer who uses it uncommonly often, not much code is going to break. - Jonathan M Davis
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 12:00:57 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 On Friday, December 09, 2011 10:19:18 Don wrote:
 Are there any cases where you're using comma outside of for loops?
 I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops.

'most people'?

Yes, I would guess that you're in the minority here.
 Occasionally, it's
 useful to use one in an expression, but on the whole, it's just  
 confusing and
 error-prone.

It is confusing to people who don't know the language. It is a simple construct. In my experience, it is certainly not error prone. If you are aware that such an operator exists.

It's error prone in cases where you use it without realising, as in the example I posted.
 The resulting code may not be as compact, but it
 wouldn't be hard to write.

It would be a PITA in some cases.

Really? Give us an example where not having comma makes things significantly difficult.
 And unless you're dealing with a programmer who
 uses it uncommonly often, not much code is going to break.

I _am_ such a programmer.

So it seems :) I don't want to make your life harder but I think this change would make life easier for a large number of people, a small amount of the time. The equation is unbalanced in favour of it's removal, IMO. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 13:01:12 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 01:11 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 12:00:57 -0000, Timon Gehr <timon.gehr gmx.ch>  
 wrote:
 On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 On Friday, December 09, 2011 10:19:18 Don wrote:
 Are there any cases where you're using comma outside of for loops?
 I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops.

'most people'?

Yes, I would guess that you're in the minority here.

'most people' do not care about this discussion, so lets stop it. :o)

Sure.
 So it seems :)

If you carefully read my posts you will find that I did never say that I am against removing the comma operator.

Excellent.
 I don't want to make your life harder but I think this
 change would make life easier for a large number of people, a small
 amount of the time. The equation is unbalanced in favour of it's
 removal, IMO.

This part of your post is somewhat contradictory.

How so? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 13:15:22 -0000, Piotr Szturmaj <bncrbme jadamspam.pl>  
wrote:

 Regan Heath wrote:
 On Fri, 09 Dec 2011 12:00:57 -0000, Timon Gehr <timon.gehr gmx.ch>  
 wrote:
 On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 And unless you're dealing with a programmer who
 uses it uncommonly often, not much code is going to break.

I _am_ such a programmer.

So it seems :) I don't want to make your life harder but I think this change would make life easier for a large number of people [...]

What about just not using comma operator? Yes, I know about keyboard issue. There are many cases when 'typoed' code compiles but doesn't work as programmer would expect. This is not limited to comma op.

True, but D has already turned a good number of those into errors. This is another example where it could for very little cost, IMO. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 13:47:14 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 I don't want to make your life harder but I think this
 change would make life easier for a large number of people, a small
 amount of the time. The equation is unbalanced in favour of it's
 removal, IMO.

This part of your post is somewhat contradictory.

How so? R

Removing the comma operator makes my life harder. You don't want to do so. You want to remove the comma operator. Conclusion: Today is Monday.

:p 1. I don't want to make your life harder, but (despite that) 2. I do want to remove the comma operator Nothing contradictory there at all, simply cost/benefit. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 08 Dec 2011 12:17:20 -0000, so <so so.so> wrote:

 On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic <dejan.lekic gmail.com>  
 wrote:

 Why is this operator still kept around?

No offense, but I find it strange/funny that you even ask why! :) Have you never used comma in for loops???

Not sure if it is that relevant for D, but good point. for(auto i=beg(), e=end(); i!=e; ++i) for(auto i, j, k;; ++i, ++k) ...

It's kinda amusing that this thread appeared just as we had a case of this here at work. The developer accidentally coded something like... if (function(..), FALSE) { } Accidentally adding the ", FALSE" /after/ the ) instead of as a new parameter to the function. (note; This was in C++ with default parameter values so the function can in fact take 1-4 args). When I pointed this out, he said "how does that even compile" and was completely unaware of the existence of the comma operator, nor (once I explained it) did he realise it was in any way related to the comma used in for loops. People simply don't think of them as being the same thing at all. Instead, people learn the comma syntax as a special characteristic of the for loop, and use it nowhere else. I think the comma operator is of little benefit (except where used in a for loop) and it is a source of bugs and we'd be better off without it. Even if it means porting C/C++ requires modification, or existing D (I doubt very much of it) breaks. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 08 2011
prev sibling next sibling parent so <so so.so> writes:
On Thu, 08 Dec 2011 18:02:11 +0200, Regan Heath <regan netmail.co.nz>  
wrote:

 When I pointed this out, he said "how does that even compile" and was  
 completely unaware of the existence of the comma operator, nor (once I  
 explained it) did he realise it was in any way related to the comma used  
 in for loops.  People simply don't think of them as being the same thing  
 at all.  Instead, people learn the comma syntax as a special  
 characteristic of the for loop, and use it nowhere else.

Not that related but my all time favorite is still: type a = a + 2; // compiles with no errors, no warnings, no explosions (that i know of)
Dec 08 2011
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
 type a = a + 2; // compiles with no errors, no warnings, no 
 explosions (that i know of)

If "type" has the default initialiser, then what is the problem?
Dec 08 2011
prev sibling next sibling parent so <so so.so> writes:
On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic gmail.com>  
wrote:

 type a = a + 2; // compiles with no errors, no warnings, no explosions  
 (that i know of)

If "type" has the default initialiser, then what is the problem?

What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all?
Dec 08 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 08 Dec 2011 13:17:44 -0500, so <so so.so> wrote:

 On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic gmail.com>
 wrote:

 type a = a + 2; // compiles with no errors, no warnings, no explosions
 (that i know of)

If "type" has the default initialiser, then what is the problem?

What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all?

Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec.
Dec 08 2011
prev sibling next sibling parent so <so so.so> writes:
On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques <sandford jhu.edu>
wrote:

 On Thu, 08 Dec 2011 13:17:44 -0500, so <so so.so> wrote:

 On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic gmail.com>
 wrote:

 type a = a + 2; // compiles with no errors, no warnings, no explosions
 (that i know of)

If "type" has the default initialiser, then what is the problem?

What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all?

Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec.

I disagree. As you said while in C/C++ same thing gets assigned random values, in D it doesn't. As a result, it changes both the coders' expectations and programs outcome. Even the definitions are different. Undefined there and defined here. I am not sure how to express this. As far as i understand you are saying; Because uninitialized variables are undefined in C, D can act as another C compiler and interpret this rule as it pleases. But in practice no compiler i know does that. And "assuming the variable initialized to some value" is a bad programming practice, which i should say the most popular among its kind. So it clashes with another thing about D, pragmatism.
Dec 08 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 08 Dec 2011 21:23:11 -0500, so <so so.so> wrote:
 On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques <sandford jhu.edu>
 wrote:

 On Thu, 08 Dec 2011 13:17:44 -0500, so <so so.so> wrote:

 On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic <dejan.lekic gmail.com>
 wrote:

 type a = a + 2; // compiles with no errors, no warnings, no explosions
 (that i know of)

If "type" has the default initialiser, then what is the problem?

What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all?

Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec.

I disagree. As you said while in C/C++ same thing gets assigned random values, in D it doesn't. As a result, it changes both the coders' expectations and programs outcome. Even the definitions are different. Undefined there and defined here. I am not sure how to express this. As far as i understand you are saying; Because uninitialized variables are undefined in C, D can act as another C compiler and interpret this rule as it pleases. But in practice no compiler i know does that.

 And "assuming the variable initialized to some value" is a bad programming
 practice, which i should say the most popular among its kind.

 So it clashes with another thing about D, pragmatism.

Dec 08 2011
prev sibling next sibling parent so <so so.so> writes:
On Fri, 09 Dec 2011 06:26:27 +0200, Robert Jacques <sandford jhu.edu>  
wrote:

 So it clashes with another thing about D, pragmatism.


It was/is one of the defining points of D AFAIK. More than being theoretical it chose to be pragmatic, to solve the problems we face day to day. For the case at hand; Say uninitialized variables in C are undefined but all the compilers do the same thing that makes it in practice defined. So the below line should execute same on all compilers. type a; Same applies to the extensions supported in all major compilers which is absent in language spec. If compilers don't support, they can't sell. To the point. If you want to keep B-D rule with the presence of such big design mistakes (C), you are not being pragmatic at all.
Dec 08 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 11:39:55 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 10:19 AM, Don wrote:
 On 08.12.2011 20:22, Timon Gehr wrote:
 Phobos would break, for example. And some of my code too.

Are there any cases where you're using comma outside of for loops?

Yes, one for every 65 LOC.
 I wonder how much would break if were made illegal everywhere else.

These are the occurences of the comma operator in directory 'std': return r2.empty ? (r1 = r, true) : false; return binaryFun!pred(r.front, e) ? (r.popFront(), true) : false; if (f.flPlus) signChar = '+', ++minw; else if (f.flSpace) signChar = ' ', ++minw; if (std.ascii.toLower(p.front) == 'n' && (p.popFront(), std.ascii.toLower(p.front) == 'f') && (p.popFront(), p.empty)) enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A') && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'), new ConvException("error converting input to floating point")); if (indexStart != 0) formatValue(w, indexStart, f), put(w, '$'); if (c == '\"' || c == '\\') put(w, '\\'), put(w, c); else put(w, c); return (++mi.m_cRefs, cast(HXModule)mi); return (++mi.m_cRefs, hModule); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : (assert(false), 6);

All of the above could be improved with the removal of the comma operator, IMO. They are needlessly complicated/confusing with it. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 11:39:55 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 These are the occurences of the comma operator in directory 'std':

Here is my /very/ quick re-write of each without looking at the context of each snippet. There may be much better re-writes in context. Re-writing this was problematic /because/ the comma operator makes things that much more confusing to me. Especially example #5 below where the last , actually separates enforce parameters! 1)
 return r2.empty ? (r1 = r, true) : false;

if (!r2.empty) return false; r1 = r; return true; 2)
 return binaryFun!pred(r.front, e) ? (r.popFront(), true) : false;

if (!binaryFun!pred(r.front, e)) return false; r.popFront(); return true; 3)
 if (f.flPlus)
      signChar = '+', ++minw;
 else if (f.flSpace)
      signChar = ' ', ++minw;

This is purely {}; avoidance it seems.. if (f.flPlus) { signChar = '+'; ++minw; } else if (f.flSpace) { signChar = ' '; ++minw; } 4)
 if (std.ascii.toLower(p.front) == 'n' &&
         (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
         (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling 5)
 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
          && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) ==   
 'N'),
         new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point")); 6)
 if (indexStart != 0)
      formatValue(w, indexStart, f), put(w, '$');

More {}; avoidance.. if (indexStart != 0) { formatValue(w, indexStart, f); put(w, '$'); } 7)
 if (c == '\"' || c == '\\')
      put(w, '\\'), put(w, c);
 else
      put(w, c);

More {}; avoidance.. if (c == '\"' || c == '\\') { put(w, '\\'); put(w, c); } else { put(w, c); } 8)
 return (++mi.m_cRefs, cast(HXModule)mi);

less (), one more ; and <enter>.. ++mi.m_cRefs; return cast(HXModule)mi; 9)
 return (++mi.m_cRefs, hModule);

as above.. ++mi.m_cRefs; return hModule; 10)
 return
      c <= 0x7F ? 1
      : c <= 0x7FF ? 2
      : c <= 0xFFFF ? 3
      : c <= 0x10FFFF ? 4
      : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6; None of the above look significantly harder without the comma operator and quite a few are far clearer (to me) without it. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
On Fri, 09 Dec 2011 22:39:55 +1100, Timon Gehr <timon.gehr gmx.ch> wrote:

 These are the occurences of the comma operator in directory 'std': ...

OMG! What ever happened to the idea that source code is meant to AID reading programs and not making it obscured. These are examples for a 'shame' file, or "how not to write useful code". -- Derek Parnell Melbourne, Australia
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 13:15:47 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 01:36 PM, Regan Heath wrote:
 4)

 if (std.ascii.toLower(p.front) == 'n' &&
 (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
 (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling

Your '//error handling' shortcut hides relevant information.

What information? With context I could be more specific about what to do for each/all.
 5)

 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
 && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
 new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point"));

This is blatant code duplication.

Of the throw line? Sure, and you can re-write with nested 'if' if you prefer. I prefer the code duplication tho.
 7)

 if (c == '\"' || c == '\\')
 put(w, '\\'), put(w, c);
 else
 put(w, c);

More {}; avoidance.. if (c == '\"' || c == '\\') { put(w, '\\'); put(w, c); } else { put(w, c); }

No comma operator necessary to avoid {}: if(x == '"' || c == '\\') put(w, '\\'); put(w, c);

Yeah, it was a /quick/ re-write without additional re-factoring (aside from removal of the comma).
 8)

 return (++mi.m_cRefs, cast(HXModule)mi);

less (), one more ; and <enter>.. ++mi.m_cRefs; return cast(HXModule)mi;

() would not be necessary.

True, but if you're going to use the comma operator, enclosing it in () at makes it more obvious you've done so. I tend to use extra () when using the ?: operator for this reason.
 9)

 return (++mi.m_cRefs, hModule);

as above.. ++mi.m_cRefs; return hModule; 10)
 return
 c <= 0x7F ? 1
 : c <= 0x7FF ? 2
 : c <= 0xFFFF ? 3
 : c <= 0x10FFFF ? 4
 : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6;

This is a *much* better rewrite: assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : 4;

Again, I was missing context.. is the return value of 6 not required in release mode?
 None of the above look significantly harder without the comma operator
 and quite a few are far clearer (to me) without it.

Yah, many of those occurences in Phobos are mostly unnecessary.

:) -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 13:42:34 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 02:28 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:15:47 -0000, Timon Gehr <timon.gehr gmx.ch>  
 wrote:
 On 12/09/2011 01:36 PM, Regan Heath wrote:
 4)

 if (std.ascii.toLower(p.front) == 'n' &&
 (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
 (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling

Your '//error handling' shortcut hides relevant information.

What information? With context I could be more specific about what to do for each/all.

You can always grep the Phobos source to get context. Basically, you are suggesting to replace the comma operator with gotos: case 'i': case 'I': p.popFront(); if (std.ascii.toLower(p.front) == 'n' && (p.popFront(), std.ascii.toLower(p.front) == 'f') && (p.popFront(), p.empty)) { // 'inf' return sign ? -Target.infinity : Target.infinity; } goto default; default: {} }

If using 'goto' is the 'correct' agreed upon style for phobos then, yes. It's not my personal preference however and I'd probably refactor it further if it was my own code.
 5)

 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'A')
 && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
 new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point"));

This is blatant code duplication.

Of the throw line? Sure, and you can re-write with nested 'if' if you prefer. I prefer the code duplication tho.

Code duplication is very error prone. Furthermore I never ever want to duplicate _error handling_ code. That just clutters up the generated machine code if the compiler does not manage to reverse engineer and generate the proper solution.

I can't comment on the machine code aspect. I don't find this particular duplication error prone, but if you do you can use the nested if that I've already mentioned.
 10)

 return
 c <= 0x7F ? 1
 : c <= 0x7FF ? 2
 : c <= 0xFFFF ? 3
 : c <= 0x10FFFF ? 4
 : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6;

This is a *much* better rewrite: assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : 4;

Again, I was missing context.. is the return value of 6 not required in release mode?

I was joking here. Your 'rewrite' of the original example changed its release mode semantics, therefore I did the same thing.

My version performs the assert in all cases, throws an assert error in the same/error cases, and still returns the correct/original values. The only change is performing the assert in all cases, so I don't see how that is a problem. Yours however is entirely broken (assuming the return value of 6 is desired/required). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Dec 2011 09:25:34 -0500, Regan Heath <regan netmail.co.nz>  
wrote:

 On Fri, 09 Dec 2011 13:42:34 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 02:28 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 13:15:47 -0000, Timon Gehr <timon.gehr gmx.ch>  
 wrote:
 On 12/09/2011 01:36 PM, Regan Heath wrote:
 4)

 if (std.ascii.toLower(p.front) == 'n' &&
 (p.popFront(), std.ascii.toLower(p.front) == 'f') &&
 (p.popFront(), p.empty))

'if' statements with side effects are yuck. I prefer the check for error and bail style but you could use multiple layers of 'if' instead.. if (std.ascii.toLower(p.front) != 'n') //error handling p.popFront(); if (std.ascii.toLower(p.front) != 'f') //error handling p.popFront(); if (!p.empty) //error handling

Your '//error handling' shortcut hides relevant information.

What information? With context I could be more specific about what to do for each/all.

You can always grep the Phobos source to get context. Basically, you are suggesting to replace the comma operator with gotos: case 'i': case 'I': p.popFront(); if (std.ascii.toLower(p.front) == 'n' && (p.popFront(), std.ascii.toLower(p.front) == 'f') && (p.popFront(), p.empty)) { // 'inf' return sign ? -Target.infinity : Target.infinity; } goto default; default: {} }

If using 'goto' is the 'correct' agreed upon style for phobos then, yes. It's not my personal preference however and I'd probably refactor it further if it was my own code.

goto in this case is acceptable. It's a goto case statement, which technically should be required for fall-through.
 5)

 enforce((p.popFront(), !p.empty && std.ascii.toUpper(p.front) ==  
 'A')
 && (p.popFront(), !p.empty && std.ascii.toUpper(p.front) == 'N'),
 new ConvException("error converting input to floating point"));

This is blatant enforce abuse IMO.. p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'A')) throw new ConvException("error converting input to floating point")); p.popFront(); if(p.empty || std.ascii.toUpper(p.front) != 'N')) throw new ConvException("error converting input to floating point"));

This is blatant code duplication.

Of the throw line? Sure, and you can re-write with nested 'if' if you prefer. I prefer the code duplication tho.

Code duplication is very error prone. Furthermore I never ever want to duplicate _error handling_ code. That just clutters up the generated machine code if the compiler does not manage to reverse engineer and generate the proper solution.

I can't comment on the machine code aspect. I don't find this particular duplication error prone, but if you do you can use the nested if that I've already mentioned.

This case is a perfect example of what is right and wrong with the comma operator. With the comma operator, the single statement avoids code duplication, which is good for maintenance. However, it's extremely hard to see what's going on. Timon, please accept that you may be one of the few who reads that statement and sees perfectly what's happening, I needed to read Regan's version to understand what it does without hurting my head too much. My opinion? I think it's better written like this: p.popFront(); bool bad = void; if(!(bad = p.empty || std.ascii.toUpper(p.front) != 'A')) { p.popFront(); bad = p.empty || std.ascii.toUpper(p.front) != 'N'; } if(bad) throw new ConvException("error converting input to floating point"); And I'd probably reread it again, and throw in some comments to help me remember what the f*** I was doing :) I don't see a smaller solution, or one that doesn't use a temporary, without using the comma operator or duplicating the throw/enforce call. -Steve
Dec 09 2011
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 14:54:16 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 10)

 return
 c <= 0x7F ? 1
 : c <= 0x7FF ? 2
 : c <= 0xFFFF ? 3
 : c <= 0x10FFFF ? 4
 : (assert(false), 6);

*Much* clearer with the rewrite.. assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : c <= 0x10FFFF ? 4 : 6;

This is a *much* better rewrite: assert(c <= 0x10FFFF); return c <= 0x7F ? 1 : c <= 0x7FF ? 2 : c <= 0xFFFF ? 3 : 4;

Again, I was missing context.. is the return value of 6 not required in release mode?

I was joking here. Your 'rewrite' of the original example changed its release mode semantics, therefore I did the same thing.

My version performs the assert in all cases, throws an assert error in the same/error cases, and still returns the correct/original values. The only change is performing the assert in all cases, so I don't see how that is a problem. Yours however is entirely broken (assuming the return value of 6 is desired/required). R

What you might be missing is that assert(false) is not compiled out in release mode. It emits a 'hlt' instruction which kills your program. However, your assert(c <= 0x10FFFF); will be removed in release mode.

I was indeed missing that. I couldn't find anything about it on the website. :) R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 09 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 09 Dec 2011 00:27:39 -0500, so <so so.so> wrote:
 On Fri, 09 Dec 2011 06:26:27 +0200, Robert Jacques <sandford jhu.edu>
 wrote:

 So it clashes with another thing about D, pragmatism.


It was/is one of the defining points of D AFAIK. More than being theoretical it chose to be pragmatic, to solve the problems we face day to day. For the case at hand; Say uninitialized variables in C are undefined but all the compilers do the same thing that makes it in practice defined. So the below line should execute same on all compilers. type a; Same applies to the extensions supported in all major compilers which is absent in language spec. If compilers don't support, they can't sell. To the point. If you want to keep B-D rule with the presence of such big design mistakes (C), you are not being pragmatic at all.

Interesting point. I agree with D being a very pragmatic language (it's one of my favorite things about it), but I come to a different conclusion. The ability to copy and paste code, i.e. source compatible, is one of the most pragmatic things a language can do. And, unlike C++, the B-D rule allows D to break compatibility and therefore convert design mistakes into invalid syntax. However, this is at the cost of preventing the invalidated syntax from being re-used for other means.
Dec 09 2011
prev sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 09 Dec 2011 15:39:09 -0000, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 12/09/2011 04:37 PM, Regan Heath wrote:
 On Fri, 09 Dec 2011 14:54:16 -0000, Timon Gehr <timon.gehr gmx.ch>  
 wrote:
 What you might be missing is that assert(false) is not compiled out in
 release mode. It emits a 'hlt' instruction which kills your program.
 However, your assert(c <= 0x10FFFF); will be removed in release mode.

I was indeed missing that. I couldn't find anything about it on the website. :) R

http://d-programming-language.org/expression.html#AssertExpression

I found that :p .. but nothing about behaviour in release/debug/etc. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 12 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Regan Heath:

 http://d-programming-language.org/expression.html#AssertExpression

I found that :p .. but nothing about behaviour in release/debug/etc.

It's a known little wart of D2. We discussed about it some time ago. I have asked for a specific and clean way to do it, but D designers have said it's not a big enough wart to deserve an improvement. And as I have predicted, it comes around to bite people in the butt. This is the opposite of perfectionism... Bye, bearophile
Dec 12 2011
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
 This is, honestly, ridiculous. On most European keyboard 
 layouts, comma is on the same key as semicolon.

switching between them as you need. You may want to add US keyboard layout (selected layout is maintained per-window).
Dec 08 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 08 Dec 2011 12:18:56 -0500, Joshua Reusch <yoschi arkandos.de> wrote:>
 Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
 for loop, where it is used to separate two statements?

If we use the comma operator only for tuples, there needn't to be a special case for loops: for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }

1) Showing that the trivial example can be expressed with tuples is a good first step. The next step is to go after some of the advanced comma usages. i.e. What's the limitations of this approach? When does it break down? 2) As per the current tuple proposals, the above is a horrendous performance sink. Granted, more tuple awareness in the compiler might fix the problem, but that awareness is more than what's in the current tuple proposals.
Dec 08 2011
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
 Ahem. So are you suggesting that (a,b) means a tuple 
 everywhere but in a
 for loop, where it is used to separate two statements?

If we use the comma operator only for tuples, there needn't to be a special case for loops: for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }

for(int x, y = 0 , 100; x < y ; x, y += 1,-1) { ... } ?
Dec 08 2011
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 10-12-2011 02:39, Jonathan M Davis wrote:
 On Friday, December 09, 2011 20:18:36 Robert Jacques wrote:
 On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin<spam here.lot>  wrote:
 On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
 Ahem. So are you suggesting that (a,b) means a tuple
 everywhere but in a
 for loop, where it is used to separate two statements?

If we use the comma operator only for tuples, there needn't to be a special case for loops: for(x, y = 0 , 100; x< y ; x, y += 1,-1) { ... }

for(int x, y = 0 , 100; x< y ; x, y += 1,-1) { ... } ?

Here's how I understood it: int x,y; // Defined somewhere in the code above for( (x,y) = (0,100); x< y ; (x,y) += (1,-1) ) { ... } So you have variable capture, assignment and add-assign happening.

I'd _hate_ to be restricted to doing the same operation in the 3rd portion of a for loop for all of its parts. The comma operator is _perfect_ for there, and I wouldn't want to see its behavior changed there regardless. e.g. things like this should continue to be perfectly possible and legal for(; cond; ++x, y *= 2) {} Tuples do _not_ have the proper semantics for a for loop. It would be one thing for the comma operator were to go away in the general case, but it would be horrible IMHO for its behavior to be changed in for loops - be it in an effort to make it act like it's using tuples or any other reason. - Jonathan M Davis

Indeed, having the comma operator in for loops is perfectly normal; even C# has this. - Alex
Dec 11 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 11, 2011 20:19:11 Robert Jacques wrote:
 A lot (all?) of for loop use cases seem to actually work in tuple form. For
 instance,
 
 for(; cond; tuple(++x, y *= 2) ) {}
 
 Will behave as expected, although there might be a performance issue.

What if one of the expression's result is void? All in all, I think that it's ludicrous to consider changing the semantics of for loops to use a tuple instead of the comma operator. It's one thing to consider eliminating the comma operator outside of for loops. It's yet another to consider adding built-in templates beyond that, and it's going _way_ too far to change the semantics of the for loop as part of that IMHO. for loops should be left exactly as they are, regardless of what happens with the comma operator outside of for loops. - Jonathan M Davis
Dec 11 2011
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 11 Dec 2011 20:25:07 -0500, Jonathan M Davis <jmdavisProg gmx.com>
wrote:

 On Sunday, December 11, 2011 20:19:11 Robert Jacques wrote:
 A lot (all?) of for loop use cases seem to actually work in tuple form. For
 instance,

 for(; cond; tuple(++x, y *= 2) ) {}

 Will behave as expected, although there might be a performance issue.

What if one of the expression's result is void? All in all, I think that it's ludicrous to consider changing the semantics of for loops to use a tuple instead of the comma operator. It's one thing to consider eliminating the comma operator outside of for loops. It's yet another to consider adding built-in templates beyond that, and it's going _way_ too far to change the semantics of the for loop as part of that IMHO. for loops should be left exactly as they are, regardless of what happens with the comma operator outside of for loops. - Jonathan M Davis

Ah, thank you. I was observing that my standard for loop syntax actually had the same effective meaning under traditional and tuple semantics, and wasn't seeing the counter example. But, for(; !a.empty && b.empty; a.popFront, b.popFront) {} would never work as a tuple.
Dec 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 09, 2011 13:00:57 Timon Gehr wrote:
 On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
 On Friday, December 09, 2011 10:19:18 Don wrote:
 Are there any cases where you're using comma outside of for loops?
 I wonder how much would break if were made illegal everywhere else.

I'm sure that it would break code, but most people consider it bad practice to use the comma operator for much outside of for loops.

'most people'?
 Occasionally, it's
 useful to use one in an expression, but on the whole, it's just
 confusing and error-prone.

It is confusing to people who don't know the language. It is a simple construct. In my experience, it is certainly not error prone. If you are aware that such an operator exists.
 And while it might break code to make the comma operator illegal
 outside of for loops, I would expect that fixing the broken code would
 generally be rather trivial.

Sure.
 The resulting code may not be as compact, but it
 wouldn't be hard to write.

It would be a PITA in some cases.
 And unless you're dealing with a programmer who
 uses it uncommonly often, not much code is going to break.

I _am_ such a programmer.

In my experience, someone like you who uses the comma operator outside of for loops much at all is incredibly rare. It's far more typical to consider the comma operator confusing and error-prone than it is to use it frequently. - Jonathan M Davis
Dec 09 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin <spam here.lot> wrote:

 On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
 Ahem. So are you suggesting that (a,b) means a tuple
 everywhere but in a
 for loop, where it is used to separate two statements?

If we use the comma operator only for tuples, there needn't to be a special case for loops: for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }

for(int x, y = 0 , 100; x < y ; x, y += 1,-1) { ... } ?

Here's how I understood it: int x,y; // Defined somewhere in the code above for( (x,y) = (0,100); x < y ; (x,y) += (1,-1) ) { ... } So you have variable capture, assignment and add-assign happening.
Dec 09 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 09, 2011 20:18:36 Robert Jacques wrote:
 On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin <spam here.lot> wrote:
 On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
 Ahem. So are you suggesting that (a,b) means a tuple
 everywhere but in a
 for loop, where it is used to separate two statements?

If we use the comma operator only for tuples, there needn't to be a special case for loops: for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }

for(int x, y = 0 , 100; x < y ; x, y += 1,-1) { ... } ?

Here's how I understood it: int x,y; // Defined somewhere in the code above for( (x,y) = (0,100); x < y ; (x,y) += (1,-1) ) { ... } So you have variable capture, assignment and add-assign happening.

I'd _hate_ to be restricted to doing the same operation in the 3rd portion of a for loop for all of its parts. The comma operator is _perfect_ for there, and I wouldn't want to see its behavior changed there regardless. e.g. things like this should continue to be perfectly possible and legal for(; cond; ++x, y *= 2) {} Tuples do _not_ have the proper semantics for a for loop. It would be one thing for the comma operator were to go away in the general case, but it would be horrible IMHO for its behavior to be changed in for loops - be it in an effort to make it act like it's using tuples or any other reason. - Jonathan M Davis
Dec 09 2011
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 11 Dec 2011 06:21:51 -0500, Alex Rønne Petersen <xtzgzorex gmail.com>
wrote:

 On 10-12-2011 02:39, Jonathan M Davis wrote:
 On Friday, December 09, 2011 20:18:36 Robert Jacques wrote:
 On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin<spam here.lot>  wrote:
 On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
 Ahem. So are you suggesting that (a,b) means a tuple
 everywhere but in a
 for loop, where it is used to separate two statements?

If we use the comma operator only for tuples, there needn't to be a special case for loops: for(x, y = 0 , 100; x< y ; x, y += 1,-1) { ... }

for(int x, y = 0 , 100; x< y ; x, y += 1,-1) { ... } ?

Here's how I understood it: int x,y; // Defined somewhere in the code above for( (x,y) = (0,100); x< y ; (x,y) += (1,-1) ) { ... } So you have variable capture, assignment and add-assign happening.

I'd _hate_ to be restricted to doing the same operation in the 3rd portion of a for loop for all of its parts. The comma operator is _perfect_ for there, and I wouldn't want to see its behavior changed there regardless. e.g. things like this should continue to be perfectly possible and legal for(; cond; ++x, y *= 2) {} Tuples do _not_ have the proper semantics for a for loop. It would be one thing for the comma operator were to go away in the general case, but it would be horrible IMHO for its behavior to be changed in for loops - be it in an effort to make it act like it's using tuples or any other reason. - Jonathan M Davis

Indeed, having the comma operator in for loops is perfectly normal; even C# has this. - Alex

A lot (all?) of for loop use cases seem to actually work in tuple form. For instance, for(; cond; tuple(++x, y *= 2) ) {} Will behave as expected, although there might be a performance issue.
Dec 11 2011