Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/gofmt: change in exponent literal notation from 1.12 to 1.13 #32580

Closed
liggitt opened this issue Jun 12, 2019 · 6 comments
Closed

cmd/gofmt: change in exponent literal notation from 1.12 to 1.13 #32580

liggitt opened this issue Jun 12, 2019 · 6 comments

Comments

@liggitt
Copy link
Contributor

@liggitt liggitt commented Jun 12, 2019

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

$ go version

go version devel +6a4b1f745d Wed Jun 12 17:10:31 2019 +0000 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/liggitt/Library/Caches/go-build"
GOENV="/Users/liggitt/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/liggitt/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/liggitt/git/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/liggitt/git/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
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/h8/3dzrjpfj76d93vbhc5f2r8tw00kjgb/T/go-build371862376=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Ran go fmt on 1.12.
Ran go fmt on 1.13.

What did you expect to see?

Results to be consistent.

What did you see instead?

Exponent numbers were normalized differently:

1.12: 100E6
1.13: 100e6

@liggitt liggitt changed the title gofmt change from 1.12 to 1.13 gofmt change in exponent literal notation from 1.12 to 1.13 Jun 12, 2019
@ianlancetaylor ianlancetaylor changed the title gofmt change in exponent literal notation from 1.12 to 1.13 cmd/gofmt: change in exponent literal notation from 1.12 to 1.13 Jun 13, 2019
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 13, 2019

I think this was an intentional change.

CC @griesemer

@liggitt
Copy link
Contributor Author

@liggitt liggitt commented Jun 13, 2019

any rationale or reference for the change? dueling gofmt across releases makes for unhappy CI and contributors. If the benefit is significant, changes make sense, but I'm not seeing it here.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 13, 2019

Correct. This was done on purpose. We do the same for prefixes, e.g. 0X123 becomes 0x123. The reason is that now that we allow 0O123, the form 0o123` is easier to read. We simply make the change everywhere, and didn't stop with exponents either (but we leave hexadecimal digits alone).

Closing as working as intended.

@griesemer griesemer closed this Jun 13, 2019
@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 13, 2019

@liggitt My apologies. With the proliferation of new number formats that are permitted, we (I mean several people in the Go team) felt that it would be good for gofmt to enforce a preferred, uniform style of capitalization.

I understand the unhappy CI - but that would be the case for any gofmt change, woulnd't it? If there's anything more "substantial" (I don't mean to disqualify your complaint) where this is causing problems, please feel free to re-open.

@liggitt
Copy link
Contributor Author

@liggitt liggitt commented Jun 13, 2019

that would be the case for any gofmt change, woulnd't it?

Yes, though usually the cost is easier to bear given the improved readability. The benefit here wasn't as obvious (we only had exponents in our codebase)

Digging into the change, it looks like this is normalizing where no normalization previously occurred, so the output of 1.13 will still be acceptable to 1.12, which reduces my concern (versions of gofmt flipping opinions about the "right" formatting makes backports to branches built with different go versions painful)

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 13, 2019

Correct. The new gofmt is now stricter. It has not changed its opinion.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.