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 <t...@tompayne.org> 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 function calls, method calls, and communication
> operations are evaluated in lexical left-to-right order. Any operands that
> are variables take the value of the variable after all function calls,
> methods calls, and communication operations have been evaluated."
>
> The presence or absence of function calls does make a difference here. In
> this example the use of the identity() function changes the result of f():
>
> func identity(i int) int {
> return i
> }
>
> func modify(i *int) error {
> *i = 1
> return nil
> }
>
> func f() (int, error) {
> i := 0
> return identity(i), modify(&i) // returns 0, nil
> }
>
>
>> On Wed, 15 Jan 2020 at 20:50, Robert Engels <reng...@ix.netcom.com> wrote:
>> 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 Wagner <axel.wagner...@googlemail.com>
>>>> wrote:
>>>>
>>>
>>> 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, error) {
>>> x := &MyStruct{
>>> // default fields
>>> }
>>> return x, x.initialize()
>>> }
>>>
>>> func NewWithFoo(f Foo) (*MyStruct, error) {
>>> x := &MyStruct{
>>> Foo: f,
>>> }
>>> return x, x.intialize()
>>> }
>>>
>>> You can say that you shouldn't do something like this, but it's IMO
>>> reasonable code to write and it expects different behavior.
>>>
>>> However, as per my previous e-mail, I would still prefer to rewrite this,
>>> of course :)
>>>
>>>
>>>> On Wed, Jan 15, 2020 at 8:33 PM Robert Engels <reng...@ix.netcom.com>
>>>> wrote:
>>>> 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 <p...@myitcv.io> wrote:
>>>> >
>>>> >
>>>> >>
>>>> >> "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 comma after "return statement" in the above
>>>> > sentence is then important: because the only "function calls, method
>>>> > calls, and communication operations" in that list of operands are (is)
>>>> > modify(&i).
>>>> >
>>>> > Hence when i (as in the first operand) is evaluated is not specified.
>>>> > And therefore it's dangerous to rely on it being one value or another
>>>> > (which it could be given the example you provide).
>>>> >
>>>> > There was even some discussion at the London Gophers November 2019
>>>> > meetup (where the conundrum was very related
>>>> > https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1)
>>>> > about whether it would be possible to statically flag potential errors
>>>> > like this.
>>>> >
>>>> > --
>>>> > 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/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.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/9EC93CAE-B11C-45E3-9D01-AC4AE5769BEE%40ix.netcom.com.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/Q7KVGTFt3nU/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/1388A9A2-F321-459A-893E-6D90D42E7255%40ix.netcom.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/712CE684-1432-4298-A4EE-91E7B4C89BF4%40ix.netcom.com.
