proposal: spec: remove string(int)

[robpike]

The conversion of an integer to a string was put in very early to bootstrap formatted
printing, if I remember correctly. It's odd, though, and no longer necessary, if it ever
was. It also causes inconsistencies, since string(0xD800) cannot produce the UTF-8
encoding for that code point (by definition, surrogates are not legal in UTF-8) so must
produce something else. We chose the "\uFFFD" since that's the only reasonable
option, but that means:

1) the result isn't obvious
2) string(0xD800) and "\uD800" do different things: the former produces the
UTF-8 for U+FFFD while the latter is statically rejected.

I propose that, in some remote future, we eliminate this conversion from the language.

[adg]

Comment 1:

I guess we're bound by the Go 1 compatibility promise to keep this until Go 2.

[rsc]

Comment 2:

Labels changed: added go2.

[rsc]

Comment 3:

Labels changed: added repo-main.

[rsc]

Comment 4:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

[dolmen]

I've been beaten by this "feature" in production code today.
My code was equivalent to this (but of course not so obvious: type, const and cast were in 3 different packages, and the cast result was an argument to a function, so that made the bad use of the cast quite hidden):

   type XType int16
   const x XType = 0x0001
   var y = string(x)

I think that go vet should raise an alert at least for my case (conversion to string of a value of a named integer type).

[robpike]

It is valid code, so vet will not complain about it. Perhaps golint should, but not vet.

[urandom]

Would it be possible to make string(int), return the string representation of the int. More users will probably expect this behaviour:

a := 42
fmt.Print(string(a)) // "42"

EDIT: got it, bad idea

[dominikh]

@urandom I would not expect an innocuously looking conversion to invoke an expensive number formatting routine. The solution to fixing a (supposedly) confusing construct isn't to replace it with another, equally confusing one.

[rsc]

No, that is not possible. It will silently break existing programs in a subtle way, for no real reason. If you want to convert an int (or a float or a bool) to a string, use package strconv. In particular, using strconv allows you more control over the exact formatting.

[alanfo]

I am beginning to wonder whether removing the string(int) conversion is going to be more trouble than it's worth, even for integer types other than rune and byte.

I see from #32479 that the intermediate step of adding a check for this to go vet or other code analyzers presents difficulties if the suggested fix breaks existing code when the integer value being converted overflows rune.

Although one wouldn't expect this to occur in practice, people will no doubt have used these conversions in weird, unexpected but (to them) reasonable ways knowing precisely what the results would be.

Incidentally, just to reinforce the point that the string(byte) conversion should continue to be allowed, my attention was recently drawn (by a link posted on reddit) to this book about writing an interpreter in Go. In the free sample chapter, on page 7, I noticed this function:

func newToken(tokenType token.TokenType, ch byte) token.Token {
    return token.Token{Type: tokenType, Literal: string(ch)}
}

The intended audience for this book is people who know enough Go to be able to make sense of the code and I don't think those people are going to be impressed if the code in the book fails to compile (or vet).

[ianlancetaylor]

It's clearly essential to find how much working code that is correctly using the conversion will break. We don't know that yet.

[ianlancetaylor]

In 1.15 we have a vet warning for this case (#32479). Putting this issue on hold until we have more experience with that. Also waiting until we can assume that everyone is using Go modules with a language version.