> 3) Write a min/max for every number type. Due to lack of overloading, each would be named accordingly (minInt64 etc). This is ugly and definitely not the "Go way"
Have a package for each type, so you can import the one you need (e.g something like math/uint64), and eventually can rename it on import as is best fitting. Also, make it an external package in golang.org/x (like godoc&al) so as not to be bound to promises regarding language stability while at the same time offering a centralized implementation.
> 4) Just use the most "general" number type and write min/max for that
This is precisely what strconv.ParseInt does[0], with some obscure, runtime evaluated integer magic values of all things (instead of readable, type-safe, compile-time asserted enums).
Have a package for each type, so you can import the one you need (e.g something like math/uint64), and eventually can rename it on import as is best fitting. Also, make it an external package in golang.org/x (like godoc&al) so as not to be bound to promises regarding language stability while at the same time offering a centralized implementation.
> 4) Just use the most "general" number type and write min/max for that
This is precisely what strconv.ParseInt does[0], with some obscure, runtime evaluated integer magic values of all things (instead of readable, type-safe, compile-time asserted enums).
[0]: http://golang.org/pkg/strconv/#ParseInt