After flag.Parse, how can a Go program tell which flags were actually set on the command line?

## Two iterators, one difference The `flag` package exposes two walkers over the flags of the default command-line set: ```go func Visit(fn func(*Flag)) func VisitAll(fn func(*Flag)) ``` `VisitAll` calls `fn` for **every flag that was declared**. `Visit` calls it only for the flags that were **set** — meaning they appeared on the command line and `Parse` assigned them. Both iterate in lexicographical order by flag name, which is also why `-h` output is alphabetical. Each call hands you a `*flag.Flag`: - `Name` — the flag name without the leading dash. - `Usage` — the help text you supplied. - `Value` — a `flag.Value`, whose `String` method renders the current value, so `%s` prints it. - `DefValue` — the **string form of the default**, captured when the flag was declared. There is also `flag.NFlag()`, the count of flags that were set, and `flag.Lookup(name)` to fetch one flag by name. ## What Visit is actually for The common use is provenance. Suppose a setting can come from a config file, an environment variable, or a flag, and the file is read *after* the command line is parsed — for example because the file's path is itself a flag. You now need to apply the file's values without stomping anything explicit. Build a set of what was typed: ```go flag.Parse() set := map[string]bool{} flag.Visit(func(f *flag.Flag) { set[f.Name] = true }) ``` and skip any key present in that set when applying the lower-priority layer. This is the escape hatch for cases where you cannot simply seed the flag's default before parsing. The second use is reporting: a startup line naming which settings the operator overrode is often the fastest answer to "why is this instance behaving differently". ## Why value comparison is not a substitute The instinct is to compare a variable to its default and call it "unset". That is wrong twice. First, an operator is allowed to pass exactly the default value on purpose — `-workers=4` when 4 is the default — and that is an explicit choice you would erase. Second, if you seeded the default from an environment variable, the "default" you would compare against is itself the environment's value, so the comparison no longer means anything. Comparison against the zero value is worse still: `0`, `""` and `false` are legitimate settings. `DefValue` has the same subtlety and it is worth stating plainly: it records the default **as it was at declaration time**. If you seeded that default from `os.LookupEnv`, `DefValue` shows the environment's value, not the compiled-in one. That makes a `VisitAll` dump honest about what would have been used, but it does not tell you which layer supplied it — if you need that, record the source yourself while resolving. ## Ordering rules `Visit` before `Parse` reports nothing, because no flag has been set yet; that is not an error and produces no warning, which is what makes it an easy bug. `VisitAll` before `Parse` works fine and shows every declared flag with its default — useful for generating documentation, useless for reporting effective values. And neither one sees a flag declared after `Parse` ran; late declarations are a bug the package will not save you from. ## Printing the effective configuration ```go flag.VisitAll(func(f *flag.Flag) { log.Printf("config %s=%s (default %s)", f.Name, f.Value, f.DefValue) }) ``` Two cautions. Redact anything secret — a token or a database password passed as a flag is already visible in the process table, and logging it makes it permanent. And print this **before** the service starts accepting traffic, so the line is at the top of the log when someone is bisecting a bad rollout, not buried after the first request. ## A note on scope Both functions operate on the package-level flag set that `flag.String`, `flag.Duration` and friends populate. Anything you build on top of them — provenance maps, effective-config dumps, a required-flags check that exits when a mandatory flag was never set — is a few lines over these two iterators and needs no library.