how common is this that it needs to be in the stdlib?

@seankhliao it can be quite handy for passing URLs as flags to binaries. String argument will be parsed using url.Parse and converted to url.URL type. This flag will be very similar to existing time.Duration flag.

Thanks, but handy is not the same as common.

A flag like this doesn't need to live in the standard library. It can be implemented entirely outside of the standard library by implementing the flag.Getter interface. The only reason that we have flag.Duration in the flag package is that we don't want to put high level concepts like flags in the very low level time package.

So the question here is: what makes this flag important enough to put into the standard library?

Thanks.

@ianlancetaylor
AFAIK, you have to create your own type in order to implement flag.Value and if you have other code that expects url.URL(not your custom type), you have to explicitly convert it like so url.URL(myFlagVar). AFAIK, you can't implement interfaces on types that you do not define. In this case url.URL type just as time.Duration are types of stdlib, and I, as a developer of web services, find it very common to provide URLs as configs to my programs.

DISCLAIMER: It's just my opinion, and I may not see a bigger picture here, or maybe there is a specific reason for not including other stdlib types to flag package.

Wouldn't it be enough to implement TextMarshaler/Unmarshaler for url.URL?

@uluyol your suggestion seems reasonable to me. I didn't know smth. like this was implemented. It's not released yet, right?

It looks like flag.TextVar will be part of Go 1.19.

@uluyol cool, but it's not a blocker to implement TextMarshaler/Unmarshaler interfaces for url.URL right now?

1.19 is the next release, so any change to url will, at the earliest, be in the same release.

OK, do I need more approvals for implementing TextMarshaler/Unmarshaler interfaces for url.URL?
shall we discuss it in this proposal or should I create a new one?

Please open a new issue (and close this one if you don't want it any more). Thanks.

closed in favor of #52638