4 ms·

What's wrong with ternary operator ("a?b:c") ? It seems many people hate it but I've never seen a reason for it. This operator is very useful and uncontroversi

What's wrong with ternary operator ("a?b:c") ? It seems many people hate it but I've never seen a reason for it. This operator is very useful and uncontroversial in Perl, it's normal (and quite readable) in selecting a value for assignment. One is expected to use good practices with it, but it is nice. Is the problem the fact that in C you can use it instead of if, selecting not values but actions, like (a > b) ? printf("A") : printf("B");

zogrodea 3y ago
I (a different person replying to your post) don't mind ternary operators, but I do prefer if-expressions which convey the same thing semantically but can be nicer to read (and also way better when chaining else-if ladders - nested ternaries can be a nightmare to read). https://stackoverflow.com/a/46843369 https://stackoverflow.com/a/46843369
- IlliOnato 3y ago
  Chained ternaries are quite readable when formatted as tables... a = (x < 5 ) ? 'LESS' : (x > 5 ) ? 'MORE' : 'SAME';
- 8372049 3y ago
  To me personally, the use case for ?: is selecting a value for a const: const value = cond ? a : b; Using an if instead would mean you can't make it const, and is usually more convoluted to read. For pretty much all other use cases, I agree that ifs are better.
  - kevindamm 3y ago
    In that case you can have the result of a function call be assigned to the const, and the function be the if/else for the value. With a well-named function it can even be more readable than the ternary.
    - IlliOnato 3y ago
      Having to create a function where a simple expression would suffice is "typing in mittens" programming...
      - kevindamm 3y ago
        Fair enough.. I actually use ternary sometimes, especially in brief return statements, and especially when both results are simple values. I only really avoid it when the result expressions are multiline. I just felt like pointing out the obvious when I saw GP's comment.
  - zogrodea 3y ago
    I was confused by your reply when I first read it (didn't quite understand it), but I think it comes from a miscommunication when I had intended if-expressions (if statements that return a value) while you had if-statements in mind. For example, the following F# code (you can run `dotnet fsi` in a terminal to try it out, if you have dotnet installed) is equivalent to a ternary expression: // the value of x is "is_not_lower" after evaluation (x is a constant/immutable value, just like a 'const' value in JS) let x = if 0 > 1 then "is_lower" else "is_not_lower" Which is equivalent to the following (in JS): const x = 0 > 1 ? "is_lower" : "is_not_lower" In F# (and also Kotlin which I linked before), you can have clean code with if-elif-else ladders while the equivalent (using nested ternaries) would be hard to read. For example: // the constant/immutable variable "comparison" is either "HIGHER", "LOWER" or "EQUAL" depending on the branch taken let comparison = if a > b then "HIGHER" elif a < b then "LOWER" else "EQUAL" In JS land (and also most common programming languages which have plain if-statements), I agree a ternary would often be preferrable as long as it's not nested.
    - IlliOnato 3y ago
      I would say that languages where "if" can be used as expression provide a different (perhaps better) syntax for the same ternary operator. a = if x then y else z is just a more verbose version of a = x ? y : z; Raku uses yet another form of the same operator: a = x ?? y :: z; Syntactic sugar :-)
      - lizmat 3y ago
        It's actually a = x ?? y !! z And that's because a single : is used for many other semantics in the Raku Programming Language. And ?? and !! standout better in code. https://docs.raku.org/language/operators#infix_??_ https://docs.raku.org/language/operators#infix_??_!!
        IlliOnato 3y ago
        You are right, of course. Sorry! "Colon belongs to Larry" :-) I think I made this mistake because :: was used in one of the drafts for Perl 6, but the final specification uses !!
dgfitz 3y ago
I don’t like them because they’re easy to write and a pain to deal with later. My biggest irritation comes when I’d like to break inside the if or else clause of a ternary and can’t. There is also more mental overhead to parse and keep in the mental stack. I have also seen them used cleanly and beautifully, but that is a rare occurrence.
- sylware 3y ago
  Something which is significantly "controversial", or has no significant and pertinent impact, should not increase the compiler technical cost. Syntax sugar is the enemy of compiler technical costs. For instance, a "feature" of significant and pertinent impact missing, in the list I provided, load and store from unaligned memory address should have their own keywords as this is really important, even though modern hardware micro-archs tolerate that at a cost. Anybody using that abomination of "struct packing" C extensions should think again: C has been meant for aligned access by default, namely unaligned access should be at a syntax cost, and should pop up from the syntax and be HARDCORE explicit. I don't even think rust syntax is that clean, am I wrong? (hopefully) For instance in linux printf, I did run in a beautiful (irony) "aligned" attribute on a stack variable. I was reading the code and I though there was a bug since I did not read the variable declaration as I was very mistaken that the variable name was enough... Yeah, should be banned from the kernel (hopefully, rust is careful to avoid that abomination in its syntax). When I have "packed" data structures, I am, usually, careful at having everything "byte" defined and use explicit macros for Xword loads and stores. "Letting the compiler do that for you" is dual edge sword. And I don't even start on the _Generic abomination, which creates so much type indirection you don't know what you are dealing with unless you read a ton more code.
- IlliOnato 3y ago
  What you mean by "breaking inside"? You cannot nest ternaries, but you can chain them (see my other comment above).
speed_spread 3y ago
I like the ternary too but to pretend that it's ok because it's useful in perl is more of a counter argument...
- IlliOnato 3y ago
  A was not using Perl as an argument, I am just much more familiar with Perl than C, so I wondered if the ternary operator works differently in C than in Perl, making it more problematic/less useful.

zogrodea 3y ago

I (a different person replying to your post) don't mind ternary operators, but I do prefer if-expressions which convey the same thing semantically but can be nicer to read (and also way better when chaining else-if ladders - nested ternaries can be a nightmare to read). https://stackoverflow.com/a/46843369 https://stackoverflow.com/a/46843369

IlliOnato 3y ago
Chained ternaries are quite readable when formatted as tables... a = (x < 5 ) ? 'LESS' : (x > 5 ) ? 'MORE' : 'SAME';
8372049 3y ago
To me personally, the use case for ?: is selecting a value for a const: const value = cond ? a : b; Using an if instead would mean you can't make it const, and is usually more convoluted to read. For pretty much all other use cases, I agree that ifs are better.
- kevindamm 3y ago
  In that case you can have the result of a function call be assigned to the const, and the function be the if/else for the value. With a well-named function it can even be more readable than the ternary.
  - IlliOnato 3y ago
    Having to create a function where a simple expression would suffice is "typing in mittens" programming...
    - kevindamm 3y ago
      Fair enough.. I actually use ternary sometimes, especially in brief return statements, and especially when both results are simple values. I only really avoid it when the result expressions are multiline. I just felt like pointing out the obvious when I saw GP's comment.
- zogrodea 3y ago
  I was confused by your reply when I first read it (didn't quite understand it), but I think it comes from a miscommunication when I had intended if-expressions (if statements that return a value) while you had if-statements in mind. For example, the following F# code (you can run `dotnet fsi` in a terminal to try it out, if you have dotnet installed) is equivalent to a ternary expression: // the value of x is "is_not_lower" after evaluation (x is a constant/immutable value, just like a 'const' value in JS) let x = if 0 > 1 then "is_lower" else "is_not_lower" Which is equivalent to the following (in JS): const x = 0 > 1 ? "is_lower" : "is_not_lower" In F# (and also Kotlin which I linked before), you can have clean code with if-elif-else ladders while the equivalent (using nested ternaries) would be hard to read. For example: // the constant/immutable variable "comparison" is either "HIGHER", "LOWER" or "EQUAL" depending on the branch taken let comparison = if a > b then "HIGHER" elif a < b then "LOWER" else "EQUAL" In JS land (and also most common programming languages which have plain if-statements), I agree a ternary would often be preferrable as long as it's not nested.
  - IlliOnato 3y ago
    I would say that languages where "if" can be used as expression provide a different (perhaps better) syntax for the same ternary operator. a = if x then y else z is just a more verbose version of a = x ? y : z; Raku uses yet another form of the same operator: a = x ?? y :: z; Syntactic sugar :-)
    - lizmat 3y ago
      It's actually a = x ?? y !! z And that's because a single : is used for many other semantics in the Raku Programming Language. And ?? and !! standout better in code. https://docs.raku.org/language/operators#infix_??_ https://docs.raku.org/language/operators#infix_??_!!
      - IlliOnato 3y ago
        You are right, of course. Sorry! "Colon belongs to Larry" :-) I think I made this mistake because :: was used in one of the drafts for Perl 6, but the final specification uses !!

dgfitz 3y ago

I don’t like them because they’re easy to write and a pain to deal with later. My biggest irritation comes when I’d like to break inside the if or else clause of a ternary and can’t. There is also more mental overhead to parse and keep in the mental stack. I have also seen them used cleanly and beautifully, but that is a rare occurrence.

sylware 3y ago
Something which is significantly "controversial", or has no significant and pertinent impact, should not increase the compiler technical cost. Syntax sugar is the enemy of compiler technical costs. For instance, a "feature" of significant and pertinent impact missing, in the list I provided, load and store from unaligned memory address should have their own keywords as this is really important, even though modern hardware micro-archs tolerate that at a cost. Anybody using that abomination of "struct packing" C extensions should think again: C has been meant for aligned access by default, namely unaligned access should be at a syntax cost, and should pop up from the syntax and be HARDCORE explicit. I don't even think rust syntax is that clean, am I wrong? (hopefully) For instance in linux printf, I did run in a beautiful (irony) "aligned" attribute on a stack variable. I was reading the code and I though there was a bug since I did not read the variable declaration as I was very mistaken that the variable name was enough... Yeah, should be banned from the kernel (hopefully, rust is careful to avoid that abomination in its syntax). When I have "packed" data structures, I am, usually, careful at having everything "byte" defined and use explicit macros for Xword loads and stores. "Letting the compiler do that for you" is dual edge sword. And I don't even start on the _Generic abomination, which creates so much type indirection you don't know what you are dealing with unless you read a ton more code.
IlliOnato 3y ago
What you mean by "breaking inside"? You cannot nest ternaries, but you can chain them (see my other comment above).

speed_spread 3y ago

I like the ternary too but to pretend that it's ok because it's useful in perl is more of a counter argument...

IlliOnato 3y ago
A was not using Perl as an argument, I am just much more familiar with Perl than C, so I wondered if the ternary operator works differently in C than in Perl, making it more problematic/less useful.