You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, slice flags are required to be specified multiple times. It could be helpful though to automatically parse commas in slice flag inputs into different values. Then again, it could make passing literal commas more confusing.
Should we support slice inputs like this: ./app -str one,two
which results in []string{"one","two"}
or should we continue to only support multiple flag uses like this: ./app -str one -str two
which results in the same [string{"one","two"}
The text was updated successfully, but these errors were encountered:
The StringSlice flag was already modified to split on commas, but we may want to revert that if we want commas to remain literals as originally designed: b5bd289
I think we could keep the default comma parsing behavior here while adding a new string slice flag type that takes commas directly without considering them a character to split input on.
An alternative could be what the stdlib flag does, which is to define a Value interface with a Set(string) error method that anybody can implement on their own types. That brings the possibility of projects such as https://pkg.go.dev/github.com/sgreben/flagvar to create Values for different use cases and the library does not need to support them all.
Currently, slice flags are required to be specified multiple times. It could be helpful though to automatically parse commas in slice flag inputs into different values. Then again, it could make passing literal commas more confusing.
Should we support slice inputs like this:
./app -str one,two
which results in
[]string{"one","two"}
or should we continue to only support multiple flag uses like this:
./app -str one -str two
which results in the same
[string{"one","two"}
The text was updated successfully, but these errors were encountered: