Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
earthboundkid opened this issue Feb 3, 2021 · 5 comments

Comments

@earthboundkid
Copy link
Contributor

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
Copy link
Contributor

rsc commented Feb 10, 2021

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

rsc commented Feb 10, 2021

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.

@rsc rsc closed this as completed Feb 10, 2021
@rsc rsc moved this from Incoming to Declined in Proposals (old) Feb 10, 2021
@earthboundkid
Copy link
Contributor Author

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… 🛳 👋

@golang golang locked and limited conversation to collaborators Feb 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Development

No branches or pull requests

3 participants