Add SliceFlag wrapper and fix bugs in existing implementations #1409
Conversation
The SliceFlag implementation and associated aliases (MultiStringFlag, etc) extend the existing slice implementations (StringSliceFlag, etc) to support actual slices as the flag value and destination. This change also fixes various bugs in the existing implementation. Notably, the StringSliceFlag.Apply implementation would modify the input (default) Value, if an env var was set, and no destination was provided. The bugs fixed in the other three implementations were all already fixed in either StringSliceFlag, or in one case (ignoring empty env var) in Float64SliceFlag.
meatballhat
added
kind/bug
meatballhat
added
the
kind/feature
|
@joeycumines This is amazing! Thank you so much for taking this on! Here comes the sad part. As much as I'm excited about the possibility of using generics, we won't be able to do this in the 2.x series until go 1.20 is released. Possible paths forward include:
|
|
Thanks @meatballhat :) I've added a build constraint + restructured it slightly, so it should no longer impact support for older versions of Go. |
|
Could I get an update on getting this merged? I don't want to forget I have this PR open, is all :) Looks like it passes CI now |
|
@joeycumines Sorry for my delay 😭 This week was 1000% more kiddo chaos than usual for me. Weekend mode: engage 🤘🏼 |
| // applyFlagValueHook wraps calls apply then wraps flags to call a hook function on update and after initial apply. | ||
| func applyFlagValueHook(set *flag.FlagSet, apply func(set *flag.FlagSet) error, hook func()) error { | ||
| if apply == nil || set == nil || hook == nil { | ||
| panic(`invalid input`) |
There was a problem hiding this comment.
Given that this is a library and this function already has an error return signature, I think I'd rather this not panic. WDYT?
There was a problem hiding this comment.
IMO, panics are ideal for "misuse of API" cases, especially internal / unexported APIs, as, generally speaking, panics are more likely to be noticed, and you want to notice any such cases. The least-effort alternative is just having it panic once it tries to call a nil function, which is similar, but more likely to go unnoticed.
If there was a use case for having it return an error, that could always be added later.
Update the v2 docs since merging #1409
What type of PR is this?
What this PR does / why we need it:
The SliceFlag implementation and associated aliases (MultiStringFlag, etc) extend the existing slice implementations (StringSliceFlag, etc) to support actual slices as the flag value and destination.
This change also fixes various bugs in the existing implementation. Notably, the StringSliceFlag.Apply implementation would modify the input (default) Value, if an env var was set, and no destination was provided. The bugs fixed in the other three implementations were all already fixed in either StringSliceFlag, or in one case (ignoring empty env var) in Float64SliceFlag.
Which issue(s) this PR fixes:
Fixes #1410
Special notes for your reviewer:
I'm not sure if the "ignoring empty env var" behavior is desirable or not. It seems like it should be made consistent, at least.
Release Notes