doc: "Named result parameters" section in effective_go.html is less clear than Go specification

[boguslaw-wojcik]

What version of Go are you using (go version)?

$ go version
go version go1.15.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/boguslawwojcik/Library/Caches/go-build"
GOENV="/Users/boguslawwojcik/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/boguslawwojcik/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/boguslawwojcik/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/02/6gpzvgbx5pq4rl60g0spdbvw0000gn/T/go-build215540397=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Run following code

package main

import (
	"fmt"
	"time"
)

func main() {
	val := foo()
	fmt.Printf("Main: %+v\n", val.Bar) // explicit
	time.Sleep(2 * time.Second)
}

type Foo struct {
	Bar string
}

func foo() (val *Foo) {
	val = &Foo{Bar: "named"}
	go func() {
		time.Sleep(time.Second)
		fmt.Printf("Goroutine: %+v\n", val.Bar) // explicit
	}()

	val2 := &Foo{Bar: "explicit"}

	return val2
}

What did you expect to see?

Main: explicit Goroutine: named

What did you see instead?

Main: explicit Goroutine: explicit

While I expect this is intended albeit slightly unintuitive behavior, the documentation says named results are initialized and tied to an unadorned return which presupposes that an explicit return is not tied. I humbly propose to alter the documentation to better reflect the actual behavior.

[go101]

The spec explains it clearer: https://golang.org/ref/spec#Return_statements