encoding/json: Number no longer accepts invalid numbers

[deankarn]

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

$ go version
go version go1.14 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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dean/Library/Caches/go-build"
GOENV="/Users/dean/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=" -mod="
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY="github.com/segment*"
GONOSUMDB="github.com/segment*"
GOOS="darwin"
GOPATH="/Users/dean/dev"
GOPRIVATE="github.com/segment*"
GOPROXY="https://proxy.golang.org"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/dean/go/json-number-test/go.mod"
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/9f/y8mlmc1n7p9_g_8dkfr3zr400000gn/T/go-build201012045=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I decoded an empty string into a json.Number
https://play.golang.org/p/BasiDL88-1O

What did you expect to see?

{Num:}
{Num:1.0}
{Num:blah}
{Num:1e3}

What did you see instead?

panic: json: invalid number literal, trying to unmarshal "\"\"" into Number

goroutine 1 [running]:
main.test(0x110164f, 0xa)
        /Users/dean/go/json-number-test/main.go:23 +0x14d
main.main()
        /Users/dean/go/json-number-test/main.go:13 +0x36
exit status 2

I realize that this was done on purpose and released in 1.14 and it technically doesn't break the Go1 compatibility promise, however, it is a big behavioural breaking change and am hoping it can be reverted.

I cannot speak for the rest of the community but I know many instances where json.Number was specifically used for this very behaviour and now would require code changes to get the same behaviour back; code changes to code that we may not even own.

It was also used because it was a std lib type that supported this behaviour that didn't pull in or make another dependency that caused abstraction leakage.

[ianlancetaylor]

Another instance of #37308 and #14702.

CC @mvdan

[deankarn]

It appears that this has been discussed pretty thoroughly, if it is to remain that's ok but if I could request the release notes or somewhere there could be documentation demonstrating the fix or showing the use of an alternative like json.RawMessage just to guide people better during the transition.

[cagedmantis]

Hey @deankarn. As you mentioned, this was discussed in #37308. The release notes contain documentation noting the change. I'm going to close this issue. if you feel like this was closed in error please comment below.