import/path: Loops no longer share loop variablesRunning them in different ways gives different results

[sunhongfan]

Go version

go version go1.23.0 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/sunhongfan/Library/Caches/go-build'
GOENV='/Users/sunhongfan/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/sunhongfan/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/sunhongfan/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/sunhongfan/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/sunhongfan/Desktop/GoLearn/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/zb/28yzr3gd0n1bhryc7ns3fpr40000gn/T/go-build4158672258=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

Code:

func main() {
	done := make(chan bool)

	values := []string{"chen", "ming", "yong"}
	for _, v := range values {
		go func() {
			fmt.Println(v)
			done <- true
		}()
	}

	// 结束前等待所有的 goroutine 执行成
	for _ = range values {
		<-done
	}
}

What did you see happen?

Running via go run .
result:

❯ go run .
yong
yong
yong

Running via go run main.go
result:

❯ go run main.go
yong
ming
chen

What did you expect to see?

The expected result should be the way to run it through the file, but why the other ways to run it get different results is very puzzling to me

[gabyhelp]

Related Issues and Documentation

• Iterate go routine with an anonymous function #37297 (closed)
• Frequently Asked Questions (FAQ) > Functions and Methods > What happens with closures running as goroutines?
• x/tools/gopls: No warning "loop variable xx captured by func literal". #60016 (closed)
• loop iterator variable error #49093 (closed)
• x/tools/gopls: loopclosure analysis runs on Go 1.22.0 #65910 (closed)
• cmd/compile: global variable initialization done in unexpected order #51913 (closed)
• go1.22.1 println & fmt.Println print different result #66287 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[sunhongfan]

I seem to have found the problem, the reason is that my go.mod file does not indicate the version number, but then there is a question, I only have the current version of the go compiler locally, and there is no multi-version management tool, since the support indicates the version of go, but it should also use my current go compiler, right? Is this a flaw?

[gophun]

I only have the current version of the go compiler locally

It goes back to the old behaviour for backwards compatibility if the Go version in go.mod is <= 1.22.

https://go.dev/blog/loopvar-preview

"To ensure backwards compatibility with existing code, the new semantics will only apply in packages contained in modules that declare go 1.22 or later in their go.mod files."

[sunhongfan]

我本地只有当前版本的go编译器

如果 go.mod 中的 Go 版本 <= 1.22，将会恢复旧的行为以实现刚性兼容。

https://go.dev/blog/loopvar-preview

“为了确保与现有代码的结构兼容，新的语义仅适用于其 go.mod 文件中声明 go 1.22 或更高版本的模块中包含的包。”

I'm referring to the fact that my mod file doesn't specify a go version, but I only have a local compiler version of 1.23.0.

[gophun]

If it doesn't specify a Go version then the go tool acts as if you had written "go 1.11" in it, since module support was introduced in Go 1.11..

[sunhongfan]

If it doesn't specify a Go version then the go tool acts as if you had written "go 1.11" in it, since module support was introduced in Go 1.11..

If I don't specify a version in the go mod, even though the compiler I have installed is 1.23.0 Since I didn't specify it, he will automatically downgrade and use go 1.11 by default?

[gophun]

It will act as if go.mod said "go 1.11", that's not the same as downgrading to Go 1.11 for everything. Some features are gated by the go line in go.mod, and it won't enable these changes. For example, you won't be able to use generics, either.

[sunhongfan]

won't

thanks bro。