New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure primary library usage is via struct literals #1774
Comments
Just to make sure I understand it correctly:
If I understood this correctly, then I agree with it. |
@bartekpacia The example you're giving is actually one that I'm not sure about 😅 In the In In So! I don't want to be too strict about any of these rules, whatever that may mean at the time. I hope that we can lean more heavily into the "declarative" differentiator of this library. I don't want to reintroduce a separate WDYT? |
One of the strongest differentiators of this library is (arguably! (I'm arguing)) how declarative it is. Ensuring the primary usage of the library is via struct literals will support this differentiation, imho.
In practice, this can certainly become awkward to the point of being a bad user experience. For example, consider the "value source" implementation
Sources: EnvVars(...)
that replaces the v2EnvVars: []string{...}
. TheEnvVars
function is not a literal declaration of a type, but the usage is expected to be within a literal declaration of aFlag
type.Judgement calls must be made!
The text was updated successfully, but these errors were encountered: