Join GitHub today
RFC: #[cfg(accessible(..) / version(..))] #2523
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
I owe some folks an answer and now I have the time, nay, the obligation, to give some. :)
I think that's fair --
Such documentation can be provided locally by the person who does the gating in the specific item that is
I find that oftentimes, folks do not do such gating for mostly convenience features like e.g. exclusive range syntax or NLL. On the off-chance that this is done, it is rare enough that a comment is sufficient.
I believe you've availed yourself of the rationale in the RFC and I think we just have a difference of opinion (unlikely to be resolved though a lot of more discussion) but I'll refer to it and similar reasonings in case others have not:
I believe this is @scottmcm's original suggestion; I'd personally be open to changing to this (but others on the team may not be) but I think it's a small enough matter to reconsider in the tracking issue.
This is feasible as long as an alternate compiler is just used for bootstrapping is substantially incomplete to be used for anything else. Otherwise, this flexibility is at the expense of users who now must consider whether some feature provided in a certain version has been removed from the alternative compiler. (I think it also makes for a specification nightmare if you have to consider what exactly that feature meant in the spec.) I think alternative compilers should not lie in this manner and claim to be of the first version for which the compiler implements all the features.
Check https://blog.rust-lang.org/ for the blog post entry. It's easy and quick to check this and anything of importance will be noted there if it concerns language features. (I know this because I write those blog posts.)
I will split the tracking issues and feature gates so as to make the implementations, discussions, and tests more focused. This should assuage your concern in practical terms. I personally don't think implementation or stabilization of one need to block the other.
You'll need to make that case to the libs team as that's not for the language team to decide. However, it's orthogonal future work so I think it's best to consider it in depth elsewhere.
#[cfg(any(not(version(1.37)), version(1.38))] compile_error!("ring only support latest stable 1.37.0");
However, I don't think I should ink that into the RFC text as it might suggest encouragement (for which there is no consensus).
I find the recent new life here, and incremental approach you are suggesting, @Centril, to be encouraging. A couple of minor points that may have gelled somewhere in the interim months:
(a) Might changing the name from
(b) Feature names could be made as specific as necessary to account for changes during the stabilization process. So for example maybe a feature we effectively have now on latest nightly is named
I agree that these are implementation details that don't need to be resolved here.
On September 13, 2019 11:28:54 AM PDT, David Kellum ***@***.***> wrote: (a) Might changing the name from `version`, to something like `min_rustc_version(1.38)` clarify that its both a `>=` bounds and only relevant to rustc versions (not any other compiler)?
I think rather than encoding `min` in the name, I'd like to treat it like a Cargo semver bound, where 1.38 means ^1.38, and we then have the option to introduce more syntax in the future.
Two points here:
The breaking ways may not affect everyone using a specific feature. As such, it may create needless churn on nightly and additionally discourage folks from using nightly. Speaking as a rustc developer myself, keeping track of this also doesn't sound like much fun to be honest.
On keeping the
I'd personally favor using an explicit
On my suggestion of versioning or sub-feature name suffixes:
I'm just suggesting that the current RFCs feature design, would allow such a scheme as a tool to manage the breakage and selectively allow future-proofing. If you don't want to use that tool, that is your prerogative. :)
We say that a release announcement of a new version of Rust includes a new version of the language version. Before this RFC, this is purely a rhetorical/theoretical/social device. Nothing can see the language version. It doesn't exist mechanically. This RFC changes that to something that is mechanical, and that should, IMO, be mentioned as a drawback, if only for academic purposes. Any industrial second implementation (Note: I don't expect there to ever be one) would have to understand the feature set of each six week release to properly set their version.
It also semi-locks us into this release versioning scheme. I say semi-locks because we could at any time freeze the cfg(version(...)) version if we decide it's bad or retroactively tie it to rustc's version instead.
Another point is that things that are gated sill need to use valid rust grammar.
Let's assume that the version 1.42 adds support for throwing function, and using .if:
This won't compile in current rust, even after this rfc is implemented, because this is not valid grammar, and rustc still check the grammar of items even if they are going to be removed by attribute macro or cfg attribute.
I suppose it would not make sense to relax the parsing rules of items that are disabled by #[cfg]
So one must wrap the item inside a macro such as
Btw, I've made a crate with a macro