proposal: embed: bring back String and Bytes for convenience/documentation

[earthboundkid]

It is getting extremely late for Go 1.16, but for 1.17, I propose bringing back the String and Bytes type aliases in package embed. They’re a convenient way to document intent and they help goimport. Plus if #43698 is accepted they can add an error if the comment is accidentally omitted.

[rsc]

This is a duplicate of #43217 (as you know).
We discussed these at length there and decided against them.
We won't reopen that discussion now.

[earthboundkid]

A lot of things were discussed at once. My feeling was that there was consensus that embed.String/Bytes should not be the only way of declaring an embed and other type aliases for string/bytes should be allowed. I didn’t think there was discussion/consensus about whether there should be an additional way of declaring an embed string/byte slice for convenience and documentation.

Let’s leave this open for a while and see if anyone gives it a thumbs up or not. If not, I’ll accept that there was a consensus against embed package aliases.

[earthboundkid]

My comment for keeping the aliases had 7 thumbs up and one thumbs down even after the issue with import restrictions was discovered FWIW: #43217 (comment)

I could be wrong but my sense was that we agreed that disallowing plain string and other type aliases was bad but having an embed.String alias for documentation reasons was good (ditto bytes).

[rsc]

In general the Go approach is not to provide multiple ways of doing something, just one standard way.
We were discussing in #43217 what the one standard way to embed into a string or []byte would be.
We decided on writing string or []byte, not embed.String nor embed.Bytes.

If we create a second standard way (and anything in package embed is clearly "standard"),
then we just invite disagreements about style recommendations for when to do one versus the other.

See for example #44143. In that case there was a good reason to have two standard things
(context.TODO and context.Background) with the same meaning, and yet we are still having
those kinds of discussions about when each is appropriate.

Here there is not a similarly compelling reason to have more than one way to do something.

Stepping back a bit, it is important to the forward progress of the proposal process generally
that we don't spend time revisiting old discussions in the absence of significant new data.
I've cited this in other issues, so maybe you've seen it, but in case you haven't, I highly recommend
John Ousterhout's article http://web.stanford.edu/~ouster/cgi-bin/decisions.php, but especially
the section on Reconsideration.

Closing as duplicate of #43217.

[earthboundkid]

I still don’t agree that this is a REconsideration, but I appreciate the argument that there should be one way to do it. At this point, the ship has sailed on Go 1.16, so bon voyage to embed.String, it’s too late for that to be the one standard, docs and tutorials are already being published… 🛳 👋