Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature flags #4940
This is my proposal for feature flags, as a mechanism for introducing breaking changes ("features"). This may include removing existing syntax, or introducing new incompatible syntax.
Feature flags are set at startup via the command line and variables (environment or universal), and cannot be changed after: you have to make a new session. They can be queried at any point in the code. Features are also grouped. For example, we would have a "3.0" group for features introduced in 3.0; this lets authors test for 3.0 compatibility in one go. The "all" group is bleeding edge.
Feature flags are only intended to be used for transitions. The "off" state is the old behavior, the "on" state is the new behavior, and in a few releases we'll remove support for running with the feature off. They are not a long-term configuration mechanism.
This is how we would use feature flags to introduce a breaking change:
All functions and completions that ship with fish need to be compatible with any feature combination, as much as is possible.
This PR introduces the feature flag mechanism, and adds a feature flag for the stderr-nocaret behavior, defaulting to off. That is, carets are still redirections, but users can opt into the new behavior where carets are ordinary characters.
This PR contains the machinery and some tests. I'm eager to hear feedback on this approach before moving forwards with docs, etc.
This sounds like a brilliant idea, and I'd love it for
I don't think we need to do it for any of the other changes.
Would it be possible to add a link to further documentation to the description? Or hook it up to
One issue with
The best I can come up with is
If I'm understanding @ridiculousfish correctly, the idea is that you wouldn't - if you're touching the script, you should just port it to where it doesn't need "feature" flags (I think "compatibility" flags might be a better name) instead of adding any flags - that would become obsolete soon.
Nice spotting. This is annoying enough that we should just continue to support '?' in all cases. That is,
What did you have in mind? The feature flags don't make any particular syntax an error, they just change its meaning.
That might be surprising when it comes to regexes -
I'd rather just
Warn when one of these features is used.
E.g. with the following script:
as a sort of static analysis to aid in porting away from deprecated features.
See e.g. #4950 - we didn't catch the remaining caret redirection because it had a space, and I think all of us just used ad-hoc regexes to check for them.