flag: no way to access name of flag.FlagSet

[lukechampine]

flag.NewFlagSet takes a name parameter in its constructor, but does not provide a way to access this name afterward. I suggest either exporting the Name field of flag.FlagSet or adding a Name() method. Happy to implement either of these if they are approved.

Motivation:
I wrote a small package that implements CLI subcommands via flag.FlagSet-based lookup trees, where the name of the flag.FlagSet is the name of the subcommand. Since it is currently impossible to access the name of a flag.FlagSet, I resorted to using unsafe.Pointer to read the name field. Obviously I would like to replace this with something more robust as soon as possible.
I acknowledge that this isn't a common problem, but I think the proposal would be reasonable even without a motivating example. The name of a flag.FlagSet is one of its defining properties, so it makes sense for it to have an associated getter. (The same argument could be made for errorHandling, I suppose.)

[cznic]

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.

[lukechampine]

@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.

[gopherbot]

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

[ghost]

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

[ianlancetaylor]

Hard to say.

[ghost]

Related: #17628

[rsc]

Per discussion with proposal review, OK.

[ghost]

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

[ianlancetaylor]

@bontibon I think so.

[rsc]

Yes, that's OK too.

[lukechampine]

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.

[ianlancetaylor]

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