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: add String and Bytes aliases #62417

Open
DeedleFake opened this issue Sep 1, 2023 · 3 comments
Open

proposal: embed: add String and Bytes aliases #62417

DeedleFake opened this issue Sep 1, 2023 · 3 comments
Labels
Milestone

Comments

@DeedleFake
Copy link

DeedleFake commented Sep 1, 2023

Reasoning

Embedding is really nice, but I've had multiple occasions where I've removed embeds of type string or []byte from a file and accidentally left in the _ "embed" import. goimports can't remove it because it can't know about the usage of a _ import, and go build doesn't complain about it because, again, it's a _ import and so it's technically used, kind of. This problem doesn't apply to embed.FS usage because the import is actually fully used, then.

Proposal

Add the following declarations to the embed package:

package embed
type String = string
type Bytes = []byte

Use of these types would not be required, but using them would allow the import to be a regular import when not using embed.FS:

package example

import (
  "embed"
)

//go:embed file.txt
var file embed.String

Making them aliases would also allow them to be used elsewhere without needing conversions, just like existing string and []byte embeds.

Alternative

I don't know if it's possible because it's comment related, but maybe a check could be added to go vet that would warn about accidentally left in _ "embed" imports without any actual //go:embed comments in the file. I think this is less ideal because it would still not be caught by go build like a normally accidentally left in import, but I'd be fine with it if other's disagree.

@gopherbot gopherbot added this to the Proposal milestone Sep 1, 2023
@zephyrtronium
Copy link
Contributor

See also #43217 and in particular #43217 (comment).

@DeedleFake
Copy link
Author

Thanks. I thought it must have been suggested somewhere before but couldn't find it either as its own proposal or as a comment on the original proposal to add embed.

@rittneje
Copy link

rittneje commented Sep 3, 2023

Now that go.mod truly enforces a minimum version requirement, is the underscore import actually still needed? Or can we say that if go.mod >= 1.X then the //go:embed directive alone is sufficient (unless you actually need embed.FS, etc.)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

4 participants