encoding/json: support decoding to []int from []string by applying tag ,string

[localvar]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   1.6

2. What operating system and processor architecture are you using (go env)?
   set GOARCH=amd64
   set GOBIN=
   set GOEXE=.exe
   set GOHOSTARCH=amd64
   set GOHOSTOS=windows
   set GOOS=windows
   set GOPATH=D:\litead\oxygen
   set GORACE=
   set GOROOT=C:\go
   set GOTOOLDIR=C:\go\pkg\tool\windows_amd64
   set GO15VENDOREXPERIMENT=1
   set CC=gcc
   set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
   set CXX=g++
   set CGO_ENABLED=1

3. What did you do?
   If possible, provide a recipe for reproducing the error.
   A complete runnable program is good.
   A link on play.golang.org is best.
   https://play.golang.org/p/A4CLM3P6Dw

4. What did you expect to see?
   decode the int64 slice successfully

5. What did you see instead?
   an error:

   json: cannot unmarshal string into Go value of type int64

according to the documentation, the behavior is correct, but this makes it hard to decode an int64 slice (although there are workarounds). It will be good if 'string' tag could also be applied to slices.

[jheiselman]

I believe that this may be affecting the ability to parse JSON responses from the Slack messaging platform. Recently, my go-based Slack bot has been failing to parse the initial response after authenticating, but nothing appears to have changed in the server response and the response does successfully pass jslint.

[odeke-em]

I've mailed CL https://go-review.googlesource.com/27453.

[gopherbot]

CL https://golang.org/cl/27453 mentions this issue.

[localvar]

@odeke-em , Thanks for the CL.
If I'm reading the code correct, tags like json:"i64" is used in the fix, this seems not consistent with other tags, for example when we want an int64, we use: json:",string"

[odeke-em]

@localvar thanks for taking a look at it, let's put comments on the CL there though.
But anyways, am using "i64" as the key and not as the auxilliary tag; it is so that the respective Go struct attribute will receive the unmarshaled data of json data key "i64", so

{"i64": ["12", "33", "999"]}

and Go code

type receiver struct {
   I64 []uint64 `json:"i64,string"`
}

the data in "i64" will be unmarshaled and assigned to I64.
It could have been

"keys" -> I64 []int `json:"keys,string"`

But let's move discussion to the CL itself to avoid noise here but also to ensure that we don't miss out on concerns that should be addressed in the CL.
Thanks.

[bradfitz]

@rsc, can I get a JSON decision here?

[rskumar]

This is like fixing someone's wrong JSON by using some magic in tags. This shouldn't be language or core libs part.

Rather, if we can attach a field processor func, where we get raw bytes and json field tag and do our work explicitly and then return expected type value or error. The returned post-processed value will then be assigned to that field by JSON unmarshaller.

[titpetric]

Hey, is there anything I could do to push this along? I have a few use cases where I need to deal with encoding a slice of uint64's, and am having issues inter-operating with javascript in the browser. I wouldn't like to resort to a typed uint64 and custom (un)marshallers to resolve this encoding issue, if there's a chance we can push this into go 1.12? I see there are a only a couple of code review comments open, and the concerns shouldn't be hard to resolve. Thoughts?

[CarlCao17]

Could the issue be pushed along the way?
I think I have encountered many times for communication with web, most of them are dealing with numeric IDs. JSON could not represent large integer numbers like int64 in Go, so usually we transfer id string to server and need to convert it to int64.

For single id, the ",string" go tag is very nice. However for batch ids request, we need to do a lot more, though we have some ways to solve it, such as implementing the customer type UnmarshalJSON method for []int64 or Int64OrStr. But we need to do these one time by one time for thoses ID requests and for Int64OrStr we need to convert it to Int64 when using Int64OrStr.
If the behavior could be in encoding/json package, I think it could be better, in my opinion.

[ianlancetaylor]

At this point we expect to move to encoding/json/v2 (63397). CC @dsnet @mvdan

[dsnet]

The v2 experiment currently recursively applies the meaning of string to elements of a Go slice or map, which would accomplish what this is asking for.

[mneverov]

@dsnet does this mean that with json v2 the field like bytes []byte 'json:"bytes,string"' will be interpreted as a string, and not base64 decoded/encoded?

[dsnet]

Close, but not quite. Since []byte by default always uses base64 representation, you'll need to also specify that it should be a JSON array, then it will work: B []byte 'json:",string,format:array"'. In essence:

• format:array specifies that []byte should be treated as any regular []T.
• string specifies that numeric types should be quoted within a string.

Thus, we can have stsring and format:array to compose nicely together.

Example.