type FlagSet struct {
        *flag.FlagSet
        Name string
}

func NewFlagSet(name string, errorHandling flag.ErrorHandling) *FlagSet {
        return &FlagSet{flag.NewFlagSet(name, errorHandling), name}
}

edit: premature click.

@cznic: that's a reasonable alternative, but it breaks interoperability with the existing flag.FlagSet type. That is, users of my API now need to wrap their existing flag.FlagSet in a new type, and the new type can't be passed (directly, at least) to functions that take a flag.FlagSet. Not the worst thing in the world, but I don't see why such a workaround should be necessary when the flag.FlagSet type already contains a name field that would serve perfectly well.

Change https://golang.org/cl/70391 mentions this issue: flag: add FlagSet.Name, FlagSet.ErrorHandling

@ianlancetaylor Would adding the proposal flag on this help in getting a decision made?

Hard to say.

Related: #17628

Per discussion with proposal review, OK.

@rsc Does the approval include exporting (*FlagSet).Output (#17628)?

@bontibon I think so.

Yes, that's OK too.

For future reference: is it typical to submit a patch to Gerrit that implements a proposal before the proposal is accepted? I was kinda hoping to do this one myself and was surprised to see someone else submit a patch preemptively.

It is not typical, but also not forbidden. Sorry you didn't get a chance at it.