func either(c bool, a, b func() string) string {
if c {
return a()
}
return b()
}
func thunk(s string) func() string {
return func() string { return s }
}
fmt.Printf("color is %s", either(temperature > 100, thunk("red"),
thunk("blue"))
</troll> ;)
On Thu, Aug 16, 2018 at 10:53 AM roger peppe <rogpe...@gmail.com> wrote:
> In my experience, this is rarely a real pain, and where it is, a
> simple function can help out.
>
> func either(condition bool, a, b string) string {
> if condition {
> return a
> }
> return b
> }
>
> fmt.Printf("color is %s", either(temperature>100, "red", "blue"))
>
> The runtime cost for simple cases is exactly the same as if it had
> been built into the language. (If you wish to rely on the lazy
> evaluation of the values with respect to the condition, I suspect that
> an if statement would be more appropriate anyway.
>
> On 16 August 2018 at 09:11, 'Axel Wagner' via golang-nuts
> <golang-nuts@googlegroups.com> wrote:
> > Hi Sam. A couple small responses inline.
> >
> > On Thu, Aug 16, 2018 at 8:13 AM Sam Vilain <s...@vilain.net> wrote:
> >>
> >> To me the biggest reason to want a ternary operator is to make it easier
> >> on the reader of the code. If there's anything that go and python have
> in
> >> common, it's that both languages are designed to be easy to read (though
> >> with notable differences in emphasis about what makes it easy), and also
> >> relatively easy to tell whether code is correct.
> >
> >
> > I am not particularly familiar with the design process of Python. But
> > judging from the result, I find that very hard to believe, TBQH. I find
> both
> > of these things - reading Python and telling whether Python code is
> correct
> > - to be very hard things to do. ISTM that if two processes claim to
> optimize
> > for the same thing but achieve such different results, then either they
> > weren't optimizing for the same thing, or one of the two failed. I'm
> > uncomfortable claiming the latter, so I'd personally argue the former:
> That
> > it may be worth considering that we should use different words for what
> > Python aims for and what Go aims for (not that I have good suggestions).
> >
> >> With a ternary, it's very clear that after the statement, the assignment
> >> has occurred.
> >>
> >> result = test ? "a" : "b"
> >>
> >> With an `if' statement, you have to read a bit more:
> >>
> >> var result string
> >> if test {
> >> result = "a"
> >> } else {
> >> result = "b"
> >> }
> >>
> >> In most cases the analysis is very simple to tell that both code
> branches
> >> assign to `result'. But there's a problem with this. This is only
> easy to
> >> see if someone doesn't then come along and insert extra code into those
> nice
> >> welcoming code blocks:
> >>
> >> var result string
> >> if test {
> >> result = "a"
> >> // insert code here
> >> funcCall()
> >> } else {
> >> // insert other code here
> >> funcCall2()
> >> result = "b"
> >> }
> >>
> >> As a result, as the code is modified, the condition that 'result has a
> >> value' is not held and you end up with the zero value instead of
> something
> >> you expected.
> >
> >
> > I don't understand what you mean. Your code seems fine, what am I
> > overlooking?
> >
> > On a larger point: I don't believe this to be a good argument. I'd argue
> > that if the logic of the latter is what you want, you will get there,
> > ternary expression or not. I'd argue that in practice, if you started
> with a
> > ternary expression, people would just remove that and write the code you
> > ended up with anyway. Because they want that logic and writing that
> > conditional statement is the way to achieve that logic.
> >
> > But I'm not clairvoyant, so who knows what would happen in actual
> practice.
> >
> >>
> >>
> >> Of course it's not as bad as in python or C because there is a separate
> >> `=' and `:=' operator, but as you can see above, this doesn't always
> come
> >> into play. If you're assigning more than just an immediate constant,
> you
> >> probably don't want to start with `:=' and then re-assign based on the
> >> conditional.
> >>
> >> It also gets much more complicated to follow for cases where you might
> >> want to use a nested or chained ternary expression, or a more
> complicated
> >> value construction which has many ternaries within it.
> >>
> >> I've lost count of the times I've had to change:
> >>
> >> return FooBar{
> >> Field: blah,
> >> }
> >>
> >> To:
> >>
> >> var foo FooBar
> >> if someCond {
> >> foo.Field = blah
> >> } else {
> >> foo.Field = bar
> >> }
> >> return foo
> >>
> >> In my experience code is clearer and easier to read if it does *not*
> >> contain re-assignments and branches, and temporary variables used only
> once.
> >> With a ternary operator, you can code like that for cases where it makes
> >> sense. I would much rather write:
> >>
> >> return FooBar{
> >> Field: someCond ? blah : bar,
> >> }
> >>
> >> my 2¢,
> >> Sam
> >>
> >>
> >> On Wed, Aug 15, 2018 at 1:13 AM, 'Axel Wagner' via golang-nuts
> >> <golang-nuts@googlegroups.com> wrote:
> >>>
> >>> In my opinion Python serves as a poor argument here. I tend to use
> Python
> >>> as a example of a grab-bag language that adds any feature anyone
> considers
> >>> useful - without considering the cost. An Anti-Go, if you will :)
> >>> Gustavo Niemeyer actually wrote this up pretty well:
> >>>
> https://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward
> >>>
> >>> So, from my perspective, if you tell me "Python did not have ternary
> >>> operators, but after long and hard discussions, they caved", what I'm
> >>> hearing is "even Python didn't really need them". ;)
> >>>
> >>> (Disclaimer: This isn't meant as a dig at Python. I think Python is a
> >>> great language. But its design goals are very different from Go's)
> >>>
> >>> On Wed, Aug 15, 2018 at 8:33 AM Sam Vilain <s...@vilain.net> wrote:
> >>>>
> >>>> I haven't seen all the discussion referenced, but I remember digging
> >>>> deep into the python language archives where Guido and others
> eventually
> >>>> relented and added ternaries (with the syntax "a if val else b"). I
> can't
> >>>> remember the argument which swung the consensus but the arguments
> against
> >>>> seem remarkably similar.
> >>>>
> >>>> Go does have a one-line ternary:
> >>>>
> >>>> var result = map[bool]string{false: "a", true: "b"}[test]
> >>>>
> >>>> It's less of a hack if you declare the lookup "table" separately.
> >>>>
> >>>> Sam
> >>>>
> >>>> On Aug 14, 2018 9:52 PM, Agniva De Sarker <
> agniva.quicksil...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Your answer is here -
> >>>> https://tip.golang.org/doc/faq#Does_Go_have_a_ternary_form.
> >>>>
> >>>>
> >>>> On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann wrote:
> >>>>
> >>>> I’m new to Go and I imagine the idea of adding a ternary operator to
> Go
> >>>> has been discussed many times. Rather than repeat that, can someone
> point me
> >>>> to a discussion about why Go doesn’t add this? I’m struggling to
> understand
> >>>> why it is desirable to write code like this:
> >>>>
> >>>> var color
> >>>> if temperature > 100 {
> >>>> color = “red”
> >>>> } else {
> >>>> color = “blue”
> >>>> }
> >>>>
> >>>> Instead of this:
> >>>>
> >>>> var color = temperature > 100 ? “red” : “blue”
> >>>>
> >>>> Is the ternary really so confusing that it justifies writing 6 lines
> of
> >>>> code instead of 1? I realize I could eliminate two lines like the
> following,
> >>>> but this isn’t a good idea if the values come from function calls
> since
> >>>> there would sometimes be needless function calls.
> >>>>
> >>>> var color = “blue”
> >>>> if temperature > 100 {
> >>>> color = “red”
> >>>> }
> >>>>
> >>>> ---
> >>>> R. Mark Volkmann
> >>>> Object Computing, Inc.
> >>>>
> >>>> --
> >>>> 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.
> >>>
> >>> --
> >>> 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.
>
--
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.
