Is it safe to return and modify primitive values during func return

(question reworded based on discussion, original question below)

The Go Language Specification gives examples showing that order of evaluation for primitives is unspecified with respect to function calls during assignment to slices and maps. None of the examples mention multi-value return though, so I'm not sure if they apply in this case or not.

Examples from the spec

a := 1
f := func() int { a++; return a }
x := []int{a, f()}            // x may be [1, 2] or [2, 2]: evaluation order between a and f() is not specified
m := map[int]int{a: 1, a: 2}  // m may be {2: 1} or {2: 2}: evaluation order between the two map assignments is not specified
n := map[int]int{a: f()}      // n may be {2: 3} or {3: 3}: evaluation order between the key and the value is not specified

Using the language of the spec, is this functions return also unspecified:

func run() (int, int) {
	a := 1
	f := func() int { a++; return a }
	return a, f() // always return 1,2 OR always returns 2,2 OR can return either?
}

If the order of evaluation is not specified then a non-toy example like the following could break at some time in the future if the compiler is updated:

func CountRows(ctx context.Context, db *pgxpool.Pool) (int, error) {
  row := db.QueryRow(ctx, "SELECT COUNT(*)")
  var count int
  return count, row.Scan(&count)
}

Original Question

I'm unclear whether the go language specification is clear on whether values returned from funcs are "returned" one at a time or once all expressions are evaluated.

Aka is this code guaranteed to always output 10 <nil> (as it does in the playground) or can it ever output 0 <nil>?

package main

import "fmt"

func main() {
	fmt.Println(run())
	// Output: 10 <nil>
}

func run() (int, error) {
	var i int
	return i, inc(&i)
}

func inc(i *int) error {
	*i = *i + 10
	return nil
}

Edit

This related question suggests that order of evaluation of the primitive return value is not specified by the specification

1. "Is this function return also unspecified?"

Yes. As you found, the language specifies the evaluation order for some things:
> 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.

Naturally, anything that is not a function call, method call or communication operation is left unspecified with respect to evaluation order in an expression, assignment or return statement.

2. "a non-toy example like the following could break at some time in the future if the compiler is updated"

Yes. Even if the compiler doesn't update. If you expect it to have any particular result that's reliant on evaluation order, then the code is already broken in the sense that the language does not say the code will do what you think it will do.

3. "are values returned from funcs "returned" one at a time or once all expressions are evaluated."

There is no such distinction to be made.

4. "is this code guaranteed to always output 10 <nil> (as it does in the playground) or can it ever output 0 <nil>?"

Yes, it can output 0, <nil>. This is essentially the same as the previous run example, where now the closure f has been refactored as a function called inc.

Yes! This is a really great question.

Another way to write this code is

package main

import "fmt"

func main() {
    fmt.Println(run())
    // Output: 10 <nil>
}

func run() (int, error) {
    var i int
    err := inc(&i)
    return i, err
}

func inc(i *int) error {
    *i = *i + 10
    return nil
}

This is the same reason why you can do the following

func main() {
	callIt()
}

func callIt() (int, error) {
	return multiReturn()
}

func multiReturn() (int, error) {
	return 0, nil
}

And additionally, you can do this as well, which can be useful if you wrap a db transaction (for example) in an error handler

func main() {
	result, err := assignInReturn()
	if err != nil {
		panic(err)
	}

    // the result here, assuming no error occurred, will be 1...
	fmt.Println(result)
}

func assignInReturn() (int, error) {
	var i int
	return i, wrapErrFunc(func() error {
		// db call
		if err := dbCall(); err != nil {
			return err
		}

		i = 1 // ...because of this. This will set `i` to 1 before `assignInReturn` returns to its caller
		return nil
	})
}

func wrapErrFunc(fn func() error) error {
	return fn()
}

func dbCall() error {
	// db query
	return nil
}

In these situations, you can be certain that the items in the top-level return will evaluate prior to being returned to its caller