cmd/vet: json.Number is easy to misuse (vet check?)

[bsiegert]

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

1.10

Does this issue reproduce with the latest release?

yes

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

linux-amd64, but any architecture really

What did you do?

I reviewed some code that contained an erroneous instantiation of a json.Number. See https://play.golang.org/p/w6cy7I1A--Q.

What did you expect to see?

The author of that code was trying to store the value 1 in a json.Number by using json.Number(1).

What did you see instead?

The type is defined as

type Number string

Thus, the following happens: the 1 is interpreted as a rune, and the string is initialized from the rune. Thus, instead of storing a 1, it stores an ASCII 0x1 character. The correct way of initializing this constant would be json.Number("1").

This seems like a good fit for a vet check, as it probably is never what was intended: catch casting a number (constant? int? rune?) into a json.Number and flag it.

I looked through our internal repo and found no uses of Number instances being initialized from runes or numbers.

Would such a vet check be accepted?

[bradfitz]

New vet checks are usually denied for a variety of reasons.

It might be accepted in @dominikh's https://github.com/dominikh/go-tools/tree/master/cmd/staticcheck though.

[rsc]

Really a dup of #3939.