Bakul, these are good points.
On the second, I used to always write (C/C++):
If (things are good) {
happy case
} else {
sad case
}
so the nesting was that the all-good was the first code block even when
multiply nested and the exceptions came later. A blunt kind of literate
programming that wants to talk about the 99% case first and the weird
things later. In Go I've converted to talk about problems all the way to
the bitter end and then when you run out of problems, do the job. Now that
you point it out, "else" falls by the wayside in this situation because it
is else when you did not return already. Each Go-style if-err-die "clause"
is consuming an else. Thank you. I had not thought of it so clearly.
The first is a good point too. The debate about the ternary operator might
be better viewed as a *completion* of short variable declaration. Block
scope means is not possible to write...
if b {
x := 1
} else {
x := 2
}
:
use X
...so the benefits of short variable declaration are lost to a choice
between redundancy as you show:
x := 1
if b {
x = 2
}
which hides the intent -- the if b is the intent and that's not evident
from x := 1. The intent is "x := either 1 or 2 depending" and that is well
expressible only when the := is in the outer scope and the "1 or 2" are
expressions from an inner one being transported across the lexical boundary
by an operator -- the "depending" operator whatever its name or form might
be.
The pro-? forces might better petition under the "make short assignments
complete" banner.
x := if b {1} else {2}
x := switch b {case true: 1; case false: 2}
x := b ? 1 : 2
or, my dream scenario, which is just a dream because of too many moving
parts to sell all at once:
allow bool to int/uint casting with obvious meaning T=>1, F=>0
allow "implicit" types in literal definitions like this:
x := {1,2}[int(b)]
...or even if one could dare hope for automatic coercion of the harmless
bool...
x := {1,2}[b]
as in
workers := {runtime.NumCPU(),1}[*ParallelMode]
...oh to dream.
On Wed, Jun 12, 2019 at 7:56 AM Bakul Shah <ba...@bitblocks.com> wrote:
> On Jun 12, 2019, at 7:36 AM, Michael Jones <michael.jo...@gmail.com>
> wrote:
> >
> > 128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to
> understand this better,
>
> There are two patterns that encourage this:
>
> x := v1
> if someCond { x = v2 }
>
> And
>
> if someCond { return ... }
>
> The second pattern acts sort of as a filter. Which is useful (fewer
> choices left).
>
> The first pattern is due to a lack of C’s ?: construct. [In light of that
> it is amusing to see try as a “function” being proposed that even does a
> conditional return!]
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CALoEmQw5xCLMFj2k9exBBuvr0SBL2zifZoUER0tmiViyGWJt0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
