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: x/tools/cmd/stringer: add -trimsuffix #60267

Open
golightlyb opened this issue May 17, 2023 · 0 comments
Open

proposal: x/tools/cmd/stringer: add -trimsuffix #60267

golightlyb opened this issue May 17, 2023 · 0 comments
Labels
Milestone

Comments

@golightlyb
Copy link
Contributor

x/tools/cmd/stringer has -trimprefix option and should add a matching -trimsuffix option.

stringer's help would then look like:

Usage of stringer:
	stringer [flags] -type T [directory]
	stringer [flags] -type T files... # Must be a single package
For more information, see:
	https://pkg.go.dev/golang.org/x/tools/cmd/stringer
Flags:
  -linecomment
    	use line comment text as printed text when present
  -output string
    	output file name; default srcdir/<type>_string.go
  -tags string
    	comma-separated list of build tags to apply
  -trimprefix prefix
    	trim the prefix from the generated constant names
+  -trimsuffix suffix
+    	trim the suffix from the generated constant names
  -type string
    	comma-separated list of type names; must be set

stringer should exit with an error if the -trimprefix and -trimsuffix flags appear simultaneously, so that we don't need to think about an ordering like -trimprefix=ab -trimsuffix=bc for an input "abc". Also, giving a constant identifier both a prefix and a suffix is not something you ever see.

Rationale

From an unscientific code search, most Go "enum"-like constants take the form:

type Type int
const (
    Foo = Type(iota)
    Bar
    ...
)

or

type Type int
const (
    TypeFoo = Type(iota)
    TypeBar
    ...
)

However, less commonly but still not uncommonly, you see

type Type int
const (
    FooType = Type(iota)
    BarType
    ...
)

e.g. even in the stdlib (admittedly these don't have a String() method anyway):

Sometimes it's clearly more natural e.g. "FragmentShader" vs "ShaderFragment", "UpperCase" vs "CaseUpper".

There are advantages to using a prefix everywhere, but this is not to argue which is better, merely that the suffix form exists.

While there's probably some mileage in extracting the stringer into a library that can build a custom stringer command that can arbitrarily rewrite names, this is not that proposal. The stringer command itself should probably not be made any more complicated than this.

@gopherbot gopherbot added this to the Proposal milestone May 17, 2023
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

2 participants