Personally i dislike the latter form because it requires me to spend extra time reading what is boilerplate that is functionally identical to a ternary.
Edit: Not impressed by the down-voting of an earnest question of someone trying to learn more about how other people see things, HN.
If-else is the only option if you want to have multiple statements in a {} block, instead of only one function call.
So it seems more consistent to use ternary for expressions and if-else for statement control flow.
I'm sorry, but i really don't follow your logic, can you try to explain it more clearly?
The classic languages with ternary (C, C++, Java, PHP, JavaScript) all have the deficiency of distinction between statements and expressions. When everything in your language is an expression, the need for ternary disappears.
Python has a ternary operator, which does return a value. It just so happens this operator uses the tokens `if` and `else`. But it's the same thing what you'd write in C or Javascript as `C ? T : F`, would be written `T if C else F` in Python. Different order of arguments and tokens, but it's still the ternary operator and not an if/else block.
You can't get a result from block statements in Python. Just because the ternary operator uses the same tokens as the if/else block, doesn't mean it's the same thing.
let x = if true { 5 } else { 6 };Languages with very different syntax like Python are of course going to have different style preferences. Eg. Python doesn't have a ?: operator at all, just an inline if-else expression, so the entire discussion of "should you use ?: for control flow" is meaningless for Python.
boolean_flag
? do_this()
: do_that();
The only possibly feasible way i see for it doing something unexpected would be if it were the last statement in a function in a language that implicitly returns the value returned by the last statement in a function; but users of such languages usually are aware that can happen.
How do they suggest that?
As far as i am aware ternaries put no restriction whatsoever on what kind of code you can put in its branches.
I don't buy the comparison with getX either, since ternaries have no name, they're just some punctuation, and even if implemented as if/else word pairs are completely vague.
It might be a convention in some circles. I don't think it's a well-established one, though.
For me, ternaries strongly suggest "expressions being run for its return value", but without any indication whether or not it's side effect-free. In practice, most of the time such expressions end up being side effect-free (getters, finders, etc.), but every now and then you do want to have a stateful expression (e.g. getting something from a map, and storing a default value there if the key is missing in the map). I believe such stateful expressions are fine to use with ternaries as well.
You just called someone out for this:
"If you're restricting what you're saying to a specific language say that bold and as the very first thing (...)"
Are you talking about a specific language now? Because some languages do put restrictions on that. Python makes a clear distinction between statements and expressions, so you don't even get the option to use a ternary in place of an if/else block.
That said, (in general) I disagree that ternaries suggest side-effect free. However, they do suggest that you care about the return value of the ternary expression. Some languages enforce this suggestion, others don't. But even for languages that don't, a ternary that silently discards its return value feels like a "cute hack" to me.