unicode/utf8: add "Rune"-less aliases

[robpike]

The names in the utf8 package are clumsy. We could add nicer aliases, such as Decode for DecodeRune.

Decode(p []byte) (r rune, size int)
DecodeString(s string) (r rune, size int)
DecodeLast(p []byte) (r rune, size int)
DecodeLastString(s string) (r rune, size int)

similarly for Encode.

[bradfitz]

I vote no. Unnecessary documentation cognitive load & godoc noise for minor improvement.

[robpike]

They are so not Go-like now and they always rub me the wrong way, but they are obviously not necessary.

[adg]

The duplication would be more gross than the long names, IMO.
But I don't even use these packages.

[jimmyfrasche]

I've used the package a few times and been bothred by the unidiomatic names, but I'd be more bothered with having to jump back and forth trying to figure out what the difference was between Decode and DecodeRune only to discover there was none. It wouldn't be clear in the package's Index, at least.

Changing the documentation of DecodeRune to "deprecated: use Decode" only exchanges awkwardness for clutter.

Could this be marked Go2? That would be the best time to clean it up all at once and simple renamings are eminently go fix-able.

[jimmyfrasche]

With #17056 I don't have any objection since the deprecated versions would be hidden by default.

[robpike]

Well, at this point we could actually add Rune-less aliases (just kidding).

[mpvl]

@robpike: actually, there is something to say for using aliases here:

• It makes the relation between old and new implementation explicit (possibly together with the deprecated comment), allowing for generic rewrite tools to update code using the deprecated versions automatically.
• There is no loss of performance if the wrapper function cannot be inlined. These functions are called in tight loops.

[robpike]

@mpvl: At the moment, aliases are only across package boundaries, so using them in this case would require new, possibly internal packages. That is not worthwhile.

But they are there for refactoring, and if the restrictions are softened then of course that would work. That was my point.

[mpvl]

@r: Ah right, too bad. Yeah, the internal package approach is out of the question.