This seems reasonable to me, though I don't think you can assume a value of -trimprefix without breaking existing code. I think it has to be opt-in.

ok, I'll keep that in mind!

That would change the behavior of stringer, as @quentinmit pointed out.

Maybe a value that's not a valid identifier could trigger it without requiring spelling the prefix out? Something like -trimprefix - as a shorthand. If so, it should return an error if there's not a common prefix other than "" so the user notices the mistake.

Unrelated, but I assume that if you did

//go:generate stringer -type=Type -trimprefix=Type
type Type uint8

const (
    UnknownType Type = iota
    TypePayPal
    TypeAmazon
    TypeWorldPay
)

The strings would be

UnknownType
PayPal
Amazon
WorldPay

Is that correct?

@minux that was actually my first idea but I thought using the type name by default was simpler, I'm not opposed to going back to that idea though if thats the consensus.

@jimmyfrasche if we implemented @minux's idea of trimming the longest common prefix when you pass just a -trimprefix flag, would that resolve the issue of having to pass a signifying value like -? Or does that still change the behaviour? (I've yet to look at the stringer code). To your other question, yes I would expect if you passed a prefix to trim (Type) and a constant didn't start with that prefix (UnknownType), you just get the unchanged constant back (UnknownType), as per your example.

@adrianduke Assuming -trimprefix is a stdlib flag package flag.String

• if you give it a default, that's what it is if the flag is not provided
• if you call it just as -trimprefix without an argument, it'll error out saying you didn't provide anything to the -trimprefix flag
• I'm not sure if you can create a custom flag that's optionally boolean and anyway that would be ambiguous.

You could have an -autotrimprefix and a -trimprefix but that seems messy. To me, having a magic name seems the best way to go, but it can't be something that either

• a shell will interpret
• the flag parser will interpret (in this case just = I think)
• or is a valid Go identifier.

Of those left, - seemed the most mnemonic.

@jimmyfrasche ah I understand now! There appears to be many valid special characters when placed as flag values (at least for BASH), heres a short list of some that make some amount of sense to me:

• -trimprefix=-: would suggest to me some kind of placeholder with special meaning
• -trimprefix=.: Current context in templates, suggests special meaning
• -trimprefix=^: reminiscent of regex beginning of line character

Although having 2 separate flags doesn't seem that horrendous of an idea, having 1 flag with a special meaning character will most certainly be harder to get across to the user rather than your example of 2 flags:

• -trimprefix=<prefix>: flag.String
• -autotrimprefix: flag.Bool

flags are cheap and explicit, special characters are exceptions and harder to communicate.

This would be useful for #15462, and I see the issue has been accepted for a while with little activity, so I have given it a go.

I have left out the automatic detection of prefixes for now. That can always be added later, with whatever extra flag or special trim value that we agree on.

@gopherbot is being slow: https://go-review.googlesource.com/c/tools/+/76650

great job! This completely fell off my radar.

This has been merged - not sure when gopherbot will catch up.

I have moved the discussion about automatic detection of prefixes to #22649.

Whoops, I forgot to use golang/go#N when closing this issue. Not gopherbot's fault at all.

Whoops, I forgot to use golang/go#N when closing this issue.

@mvdan Are you using the latest version of git-codereview binary? I'm pretty sure it's supposed to catch that kind of mistake via pre-commit hooks or so. See here.