I'm a big fan of the ternary operator in general. Maybe this is because I'm
an old timey Lisper. A lot of the things people see as "abuse" or "too
complex" are equally problems with || and &&.
This is also true for Jan's point: that ?: affects control flow by omitting
execution sometimes. It would be lovely to say that in an expression, the
subexpressions are always evaluated. But Go did the usual thing, declaring
that && and || proceed conditionally.
If x and y are booleans, in fact, then "a ? x : y" is identical to "(a &&
x) || (!a && y)". We have all see boolean spaghetti. At the same time, I
get sad whenever I see things like "if a { return x == y; } else { return
false; }".
I don't mind Go's choice, however. It's a pragmatic and sensible choice: a
bunch of people, for whatever reason, find && and || easy to reason about,
and ?: annoying. Making code transparent is an important goal, so if you
want to target those readers, avoid ?:. And a language like Go, designed to
facilitate making things easy to understand over maximum economy of
characters, sensibly omits ?:.
This fits with good Go style, which tends to avoid "else" more than a lot
of other languages, making ?: standout all the more, with it's mandatory
"else" clause. And, unlike && and ||, ?: works with all types, thus making
it more pervasive when used.
Frankly, I would have preferred the Pascal approach here, which is more in
line with what Jan says: decouple entirely control flow from syntax of
expressions, and stop the experiment of having expression syntax imply
control flow. That means that && and || might "short circuit" but also
might not, and you would not be able to assume anything about the order of
subexpression execution. But, at the same time, I have no quarrel with the
pragmatic decision for Go to define those exactly instead.
On Thu, Apr 25, 2019 at 3:15 PM Jan Mercl <0xj...@gmail.com> wrote:
> On Thu, Apr 25, 2019 at 8:58 PM <lgod...@gmail.com> wrote:
> >
> > Rob : how can it be abused if the compiler wont allow nested ? operators
> ??
>
> Rather easily. Just by fuzzilly mixing the otherwise purposely
> distinct syntax of expressions and control flow.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
