proposal: spec: define return statement's result assignment order?

[bradfitz]

A coworker sent out a code review with:

func As(err error) (_ Error, ok bool) {
	var e Error
	return e, errors.As(err, &e)
}

... and during review I said I wasn't sure whether it works. Turns out it worked but it's undefined. It happens to work in cmd/compile and doesn't work in gccgo.

The spec defines assignment order for e.g. a, b = foo(), bar() or a, b = b, a but not for return.

Another example which has different results between gc and gccgo: https://go.dev/play/p/SDMlczFBshC

I propose the spec defines this. My preference would be left to right assignment to results.

But admittedly it might break code like above. (which we fortunately rewrote to be simpler and explicit)

/cc @ianlancetaylor @griesemer (sorry)

[ianlancetaylor]

CC @mdempsky

[griesemer]

I'd think that returns work like assignments (of the result values to the result variables) and thus should behave the same way with respect to evaluation order. (Haven't investigated the spec yet.)

[mdempsky]

Note that even x, y = e, f(&e) is undefined as to whether e is evaluated before or after the f(&e) call.

FWIW, cmd/compile already uses the same logic to handle assignment and return statements.

[go101]

Related: #27821 (Edit: sorry, it should be #27804)

[beoran]

Perhaps this should be documented as an implementation restriction? "A compiler may disallow return statements for which the order of evaluation cannot be determined due to side effects." Or something similar?

[go101]

It can determine for sure, it just doesn't now.