math: make the constants typed

[chmllr]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.8.3 darwin/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="~/.gocode"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.8.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.8.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6v/mjqvzyld5dn00gt1bj78tsrw0000gn/T/go-build139891339=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

I naively expected, that math.MaxInt64 is of type int64, when I do:

x := math.MaxInt64

More details: https://play.golang.org/p/UGmUgctFjn

What did you expect to see?

That this constant is of type int64 and this type would propagate to the variable I initialize by assignment.

What did you see instead?

x is of type int

[cznic]

Making the constants typed would render them useless/hard to work with more often than not. See also blog: Constants.

[ALTree]

This will break the go1 promise of compatibility, so it's not something that can be changed before an hypothetical go2. As explained in the blog post linked above, having all the math constants live in the same space (the space of untyped numbers) has many advantages.

Closing this, since it was brought up many times in the past and I don't think making the constants typed was ever seriously considered.

[chmllr]

@ALTree thanks for the explanation!

@cznic you say that making smth like MaxInt64 of type int64 would render it useless or hard to work more often than not. That means, you have multiple examples in mind. Could you please bring at least one, where the type would make this constant hard to be used? A genuine question. Thank you!

[cznic]

Eg. https://play.golang.org/p/uiosl9s4h0

[chmllr]

Thanks, but you misunderstood. I was referring to exactly the constant i mentioned in my issue:

Could you please bring at least one, where the type would make this constant hard to be used?

[ALTree]

Well, MaxInt64 being typed, for example, would make it harder to explain why some constants are untyped while others are not : )

[chmllr]

I understand. Still, the example of @cznic shows that an untyped constant allows to be less explicit and some magic starts to creep into code — exactly the sort of things Go tries to avoid usually. But yes, you cannot please everyone all the time...

[cznic]

I was referring to exactly the constant i mentioned in my issue:

The issue title is "make the constants typed". Anyway: https://play.golang.org/p/UoEmbimvv3

[cznic]

BTW: The example does not make sense, but the point is comparing typed constants no longer works across types.

[chmllr]

@cznic yes this is what I suspected: I see no point in untyped math constans in real world usage. Even the example with uint8 is something I'd prefer not to work like that. So I'm fully ok with this not being fixed ever. I'm just still not convinced that it is a "feature" and tried to understand where's the flaw in my thinking.

Thanks everyone!