This would cause the flag package to have a dependency on math/big, which would be a non-trivial dependency to absorb. Also, if flag supports math/big types, what would be the metric that we decide what types it supports? Should it also support time.Time?

As a counter-proposal, perhaps flag should support anything that implements encoding.TextMarshaler and encoding.TextUnmarshaler.

Perhaps, the API should be:

func TextVar(p encoding.TextUnmarshaler, name string, value encoding.TextMarshaler, usage string)

and usage could be like:

var n big.Int
flag.TextVar(&n, "n", big.NewInt(3853882583591558728), "Run integer factorization for this number")

or like:

var t time.Time
flag.TextVar(&t, "start_time", time.Now(), "Start processing logs at this time."

I see several advantages of this approach:

1. it avoids causing the flag package to depend on other packages just to support a given flag type,
2. it works for more types than just big.Int, and
3. it relies on a well defined interface for converting text to structured Go values and vice-versa.

There is some type safety problems with my proposed API, where the p and value arguments are not guaranteed to be the same type or pointers to the same type. This could be fixed with generics.

It is so easy to write your own implementation of flag.Value that adding more types of flags to the package requires a very strong justification.

If it's just a one-off, it can be even shorter using the new flag.Func:

n := big.NewInt(3853882583591558728)
flag.Func("n", "Run integer factorization for this number", func(s string) error {
	if _, ok := n.SetString(s, 10); !ok {
		return fmt.Errorf("bad integer %q", s)
	}
	return nil
})

https://play.golang.org/p/U5v9HWN8zF5

A detriment of flag.Func is that it doesn't display the default value, which I personally found to be an unfortunate UX hindrance.

I filed #45754 as a counter proposal based on my comment above.

FWIW, the original implementation of flag.Func took a default value string, but it was dropped because you can just add “(default x)” to the usage string.

An advantage of having the flag package manage printing the default value is that updating the actual default value in the code doesn't accidentally cause the manually written default value to become stale.

Based on the discussion this proposal will clearly not be accepted, so closing. Please comment if you disagree. Thanks.