Using unstable features.

[tkaitchuck]

This is a follow up to the discussion here:
SergioBenitez/version_check#23
and here:
#238
CC: alexcrichton, dtolnay, RalfJung, SergioBenitez

There has been a lot of back and forth on this issue, and everyone seems to agree that: "If everyone always followed theses rules there wouldn't be any issues" the problem is nobody agrees on which set of rules, and thus nobody is happy.

To make this a bit concrete imagine the following scenario:
There is an application called "SuperParserCli" it depends on "SuperParser", which in turn depends on "SimdyQuote", which depends on "HashBrown" which depends on "aHash". "SuperParserCli" also depends on "tracing-log" which also uses "aHash". There is a second app "WebChat" which depends on "tracing-log" and "actix-web" which also depends on "aHash".

There are three different classes of developers building these crates. The library developers, the app developers, and the compiler developers. They have different needs and requirements.

The application developer wants:

1. Their application to work as expected on any version of the compiler.
2. To be able to take advantage of the latest and greatest perf features.
3. To not have to understand how their entire transitive dependency tree works internally.
4. To guarantee their code won't be broken by upgrading a dependency

The library developer wants:

1. To be able to support very old versions of the compiler.
2. To be able to provide code that takes advantage of experimental features
3. To not have to follow compiler release schedules and change their code in response to updates from the compiler.

The compiler developers want:

1. To be able to gather feedback from real users on features before their release.
2. To be able to run builds of apps with two versions of a compiler to check for difference in the compiler.

Suppose we propose the rule:

• Libraries detect feature availability and enable features base on that.

How would this affect "SuperParserCli" and "WebChat"?

• The library developers are happy because their 1-3 are satisfied.
• The application developers of both apps are mostly happy as their 1-3 are satisfied. However 4 is somewhat tricky as they don't have control over if the feature is on or not. If it works, they are happy, but if not they could be broken without the option to roll back.
• Compiler developers are happy about 1 because they get lots of feedback but are very unhappy about 2. The problem is that they would like to compare how the compiler changed but they cannot isolate just the compiler changes because the code is changing out from under them and they have no control over it.

The problem here is the library developer wants to know if a feature should be on or not, and is just guessing that everyone wants the feature on if possible. But this guess can be wrong. Ultimately the process building the binary should be providing that information. So suppose instead we propose the rules:

• Every library should have a 'nightly' feature flag and only use feature when the flag is enabled.
• If nightly is enabled on a crate it enables nightly on it's dependencies.

How would this affect "SuperParserCli" and "WebChat"?

• If there are simd instructions or other perf option available in nightly, "aHash" and "SimdyQuote" could be written to use it behind the nightly flag.
• All the crates would need to add support for a nightly flag.
• SuperParserCli and WebChat have to modify their Cargo.toml depending on if they are building on nightly or not. In WebChat's case they even would have to add a direct dependency on aHash even though they don't actually depend on it, just to enable a feature flag. There really isn't a way to work out how to do this without going through all of their transitive dependencies and seeing which ones they want to turn on the flag for.
  • This violates their 2nd and 3rd requirements
• When a feature moves from unstable to stable SimdyQuote and aHash have to update their code to move it out from under a nightly flag. This is a backward incompatible change because they have to bump their MSRV in the process.
  • This violates their 1st and 3rd requirements
• After the feature lands on stable it may be a long time before apps see the benefit. Because first "aHash" needs to push out a new release, then HashBrown, SimdyQuote, and SuperParser each need to update their toml to the new version of their dependency, and increase their MSRV, and create a new major release.
  • This violates App developer's 1st requirement as this process may take years because at each level they will be hesitant to create a new major release just to bump a downstream dependency version, and because it is a major version upgrade they will want to do testing.

This is much worse. Its creating a ton of churn in the ecosystem at multiple levels introducing breaking changes for updates that don't need to be breaking or even a change at all. Clearly the assumption: "feature exists == feature on" has serious drawbacks, so there needs to be a way for enabling and disabling features to be done at compilation time.

Right now the only option is on Stable all features stabilized at or below that version are enabled and on nightly all features that have been developed as of that version are enabled. Those might be good defaults, but perhaps it would be more helpful if these could be set by config flag.

For example if there were a flag for "run with features that tagged for release at or below 1.74" this would allow:

• Library developers to ask if the feature is on, and get the correct results whether it is off because:
  • It is not yet stabilized
  • It was stabilized but the code is being compiled with an older compiler
  • It was stabilized but this is a compatibility test.
• This means they don't have to think about compiler release schedule and don't generate ecosystem churn.
• App developers get what they want when they want it.
• Compiler developers to isolate changes.
• If anywhere there is a build issue relating to a feature there is a flag to disable it as a workaround.

[tkaitchuck]

See also:
SergioBenitez/version_check#22