Re: [go-nuts] Re: Ternary ... again

Normally the FooBar is full of other fields, necessitating the single field patch. On Sat, Aug 18, 2018, 1:17 PM Tim Peoples wrote: > Regarding your issues with the following... > > >> I've lost count of the times I've had to change: >> >> return FooBar{ >> Field: blah, >> } >> >> To: >> >>

Re: [go-nuts] Re: Ternary ... again

Regarding your issues with the following... > 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 > ...I hardly consider that to be idiomat

Re: [go-nuts] Re: Ternary ... again

On Friday, August 17, 2018 at 5:56:05 PM UTC+8, Liam wrote: > > People have a wide range of perceptive and cognitive abilities. People > also have difficulty imagining the very different abilities that others > possess. > > I find constant vertical scanning and scrolling to be distracting and t

Re: [go-nuts] Re: Ternary ... again

People have a wide range of perceptive and cognitive abilities. People also have difficulty imagining the very different abilities that others possess. I find constant vertical scanning and scrolling to be distracting and thus inefficient. So I won't use a tool that adds line breaks to my code, an

Re: [go-nuts] Re: Ternary ... again

Ah, very nice! Tho I can't tell from scanning the readme which features are different than go fmt. On Fri, Aug 17, 2018, 1:17 AM Matthias B. wrote: > On Thu, 16 Aug 2018 16:54:35 -0700 > Liam Breck wrote: > > > Indeed, the problem is largely go fmt, I already raised this, but no > > one picked

Re: [go-nuts] Re: Ternary ... again

On Thu, 16 Aug 2018 16:54:35 -0700 Liam Breck wrote: > Indeed, the problem is largely go fmt, I already raised this, but no > one picked up on it: > > I use this one-liner: > > v := a; if t { v = b } > > This is not compatible with go fmt, but that tool's effects are > undocumented (see issue

Re: [go-nuts] Re: Ternary ... again

On Friday, August 17, 2018 at 8:53:15 AM UTC+8, Liam wrote: > > I find that one-concept-per-line, yielding more compact functions, is > easier to focus on, as it reduces vertical eye scanning and scrolling. > > A single-line if stmnt and my switch example demonstrate > one-concept-per-line. > > T

Re: [go-nuts] Re: Ternary ... again

Yep, the problem is due largely to gofmt. Ternary operator is easily misused and hard to read if it is nested. That's why i prefer if expression(without needing to add a new operator and even if it was deep nested in the worst case, its complexity would equal a deep nested if statement,its read

Re: [go-nuts] Re: Ternary ... again

I find that one-concept-per-line, yielding more compact functions, is easier to focus on, as it reduces vertical eye scanning and scrolling. A single-line if stmnt and my switch example demonstrate one-concept-per-line. go fmt aspires to produce an odd sort of poetry, which I find inefficient. It

Re: [go-nuts] Re: Ternary ... again

How is a ternary more readable? I've found that they make code more complex and unreadable, in both C and the proposed go, and the one-liner you provide is equally or more unreadable than the more verbose if statement. On Thu, Aug 16, 2018, 16:55 Liam Breck wrote: > Indeed, the problem is largel

Re: [go-nuts] Re: Ternary ... again

Indeed, the problem is largely go fmt, I already raised this, but no one picked up on it: I use this one-liner: v := a; if t { v = b } This is not compatible with go fmt, but that tool's effects are undocumented (see issue 18790 which was declined), an

Re: [go-nuts] Re: Ternary ... again

On Wed, 15 Aug 2018 07:46:51 -0700 (PDT) Hoo Luu wrote: > 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道: > > > var color = temperature > 100 ? “red” : “blue” > > > Although this feature will not be accepted, we could just talk about > it. I prefer 'if-expression' to ternary. > > var c

Re: [go-nuts] Re: Ternary ... again

On Thursday, August 16, 2018 at 11:59:00 AM UTC+3, Axel Wagner wrote: > > 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"

Re: [go-nuts] Re: Ternary ... again

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")) ;) On Thu, Aug 16, 2018 at 10:53 A

Re: [go-nuts] Re: Ternary ... again

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"))

Re: [go-nuts] Re: Ternary ... again

Hi Sam. A couple small responses inline. On Thu, Aug 16, 2018 at 8:13 AM Sam Vilain 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

Re: [go-nuts] Re: Ternary ... again

Looking back at the PEP ( https://www.python.org/dev/peps/pep-0308/ ), it seems that the main argument was that people were working around the lack of it in ways that led to subtle bugs using 'and' and 'or'. I seem to have inadvertently demonstrated that it's possible to do this in an obfuscated (

Re: [go-nuts] Re: Ternary ... again

Mark, Some considerations that may be unclear when approaching Go and considering anything familiar from other languages that is not in Go... MAKING DECISIONS Go's designers are experienced. with central roles in UNIX, C, GCC, Modula, etc., and also across teams of various scales and diversities

Re: [go-nuts] Re: Ternary ... again

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/

Re: [go-nuts] Re: Ternary ... again

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 rema