flag: should provide call backs as part of Parse()

[gopherbot]

by brady:

Ideally I would like to be able to add callbacks to the flags library that get called
after all the flags have been parsed, but before flags.Parse() returns. This would give
a library which uses flags the ability to check complicated argument's in a way that
still returns an "error" in the flag parsing step of the main application.

A basic example of the concept: a library accepts two arguments, "-stdout" or
"-quiet". Use of both flags is an error to the library. I can either do the
argument processing the first time a call into the library is made which cause cause a
strange error path to the user ("it ran for 4 minutes they barfed out an argument
error!"). Alternatively the main function can be littered with initLibraryX(),
initLibraryY() like calls after the flag parsing but before execution.

With a callback in flag it would be possible to return a flag error at parse time
without intrusion into main by every library included. It also becomes possible to
initialize libraries like complex logging from the flags before the first call is made.

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-none.

[robpike]

Comment 2:

Libraries shouldn't set flags with such conditions, and the flag package is not intended
to support that design. If the flags are defined in main, as intended, the error
checking can occur after the call to flag.Parse in main.

Status changed to WorkingAsIntended.

[gopherbot]

Comment 3 by brady:

An example of where this becomes necessary is basically any flag used in testing since
it is impossible to interject some kind of setup between flag processing and test start
without having to put a sync.Once object at the top of every single test (since who
knows which will run given the users command line flags.. etc)
So if the intention is that the flag library never be used by anything but main then I
guess I can see your argument. Ideally though a library could use flags to set things
that impact it at runtime rather than forcing the main() function to cram all of that
logic in. For example, setting up proxy settings might be a flag driven function (as
well as being exposed via helpers in the library directly). This becomes much more
important as abstraction layers get setup. Say you want a flag that says which API
endpoint you should target as part of your client library, should the author of the
application have to know about the existence of these options and program them into
main() even though it doesn't impact their code path in any way?
I like go for having a common flag library that unifies the ability for many different
things to all act the same and not requires the author of main() to have knowledge of a
library used three abstraction layers deep, while still giving the end user to have the
ability to change the flag if necessary. It ends up like init(), a way for the caller to
set things up prior to things getting real such that blah.Do() doesn't need to be
littered around in a hundred places.