Comment 1:

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

Comment 2:

Labels changed: added go2.

Comment 3:

Labels changed: added repo-main.

Comment 4:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

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).

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

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

@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.

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.

It's not totally clear to me if this proposal also removes string(rune). I hope not since it's very useful for debugging and constants as griesemer noted.

I don't think removing it totally is the solution. If string(rune) using utf8.RuneError replacement isn't obvious to someone, it makes more sense to me that they accept that is the case rather than remove it. It is a stone written fact that strings are valid utf8. It behaves just like string([]rune) and string([]byte), which behave just like utf8.EncodeRune, except that for the latter you have to add an import and write way more code.

It's totally fair to make string(int) have to be string(rune) however.

I think it's clear that we have to continue to support string(r) where r has type rune. And it's likely that we have to continue to support string(b) where b has type byte or, equivalently, uint8. So what we are talking about removing is the conversions of other integer types to string.

Treating rune and byte/uint8 as a special case is not as bad as it may sound; we already do exactly that for converting values of type []rune and []byte (but not slices of other integer types) to string.

Change https://golang.org/cl/212919 mentions this issue: go/analysis: add pass to check string(int) conversions

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).

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

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.