Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

I could not agree more with Axel's assessment, and wanted to emphisize it for any Go-noobs reading this. An important part of the go philosophy is to write code that is as clear and simple as possible. It is not about compact code, or 'clever' code. Code should be easy to understand, even when

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

Thanks again - I'm learning a lot here! For info, the background here is that I've been writing code like: type T struct { SomeField int } func NewTFromJSON(data []byte) (*T, error) { var t T return &t, json.Unmarshal(data, &t) } which wraps up error handling into a si

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

On Wed, Jan 15, 2020 at 12:24 PM Tom Payne wrote: > > Thanks all for the insight and explanation. Could I suggest tweaking the Go > language specification to emphasize the separation, so it reads: > >"when evaluating the operands of an expression, assignment, or return > statement, then all

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

That is why this should be tightened down imo. It’s obscure cruft that needs to be accounted for when refactoring. > On Jan 15, 2020, at 2:23 PM, Tom Payne wrote: > >  > Thanks all for the insight and explanation. Could I suggest tweaking the Go > language specification to emphasize the sepa

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

Thanks all for the insight and explanation. Could I suggest tweaking the Go language specification to emphasize the separation, so it reads: "when evaluating the operands of an expression, assignment, or return statement, *then* all function calls, method calls, and communication operations are

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

I disagree here. Knowing the order of operations/evaluation is part of knowing the language. If that’s the case it should be undefined (which forces a rewrite) not chose a behavior that seems contrary to the documentation and common practice in this area. > On Jan 15, 2020, at 1:39 PM, Axel Wa

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

I don't think "clearly this behavior is not what you would want" is a valid generalization. type MyStruct{ // … } func (x *MyStruct) initialize() error { // does some common verification and populates some internal data structures return nil } func New() (*MyStruct, e

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

And, just as an addendum: IMO, if the result depends on the order of operations in a statement, prefer to rewrite it. Like, even if you are satisfied with the behavior you are seeing *and* you can rely on it - it should be clear by now that anyone looking at it will have to expand new effort unders

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

I think the way to look at it is “what would be the behavior of if you were inline creating and initializing a struct containing both values” - clearly this behavior is not what you would want or expect. > On Jan 15, 2020, at 1:25 PM, Paul Jolly wrote: > >  >> >> "when evaluating the opera

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

> "when evaluating the operands of an expression, assignment, or return > statement, all function calls, method calls, and communication operations are > evaluated in lexical left-to-right order." My understanding goes as follows: the operands of the return statement are i and modify(&i). The

[go-nuts] Unexpected evaluation order in a return statement with multiple operands

The Go language specification on order of evaluation states: "when evaluating the operands of an expression, assignment, or return statement, all function calls, method calls, and communication operations are evaluated in lexical left-to-right