-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Update const-stability rules because we're not in min-const-fn times any more #129815
Comments
The thing that makes this currently not work well is that we can't just do #[unstable(feature = "ptr_alignment_type", issue = "102070")]
#[rustc_const_stable]
pub const fn as_usize(self) -> usize { We need to say under which feature gate and since when the function is stable, which makes no sense for a function that is still unstable. Really here we want to use We have at least one feature gates exist just due to this: Maybe we need a new attribute like |
Another issue with the current system around We should define what exactly the goal of this "transitive stability check" for I think the goal should be to protect language features and intrinsics from being const-exposed on stable, even transitively. We don't really care about unstable library features being const-exposed on stable. So we need to partition the
Furthermore, every function that is directly const-callable on stable needs to be in the first set. Proposed designFundamentally the main thing I think I want to change is to disambiguate whether a So overall I would propose the following:
This variant puts a The status quo is that we interpret |
FWIW that doesn't work, stdarch has a ton of unstable But we can at least ensure that stable |
The
rustc_const_unstable
/rustc_const_stable
system was designed in a time when mostconst fn
in the standard library were not meant to be const-stable, no matter whether they are#[stable]
or#[unstable]
. However, as time passes, it becomes more and more common that functions areconst fn
from the start, and become const-stable the same time they become stable. So maybe we should reconsider some aspects of that system.In particular, I think it would make sense to treat a function like this
as-if it also carried a
rustc_const_unstable
attribute (with the same feature gate and issue as theunstable
attribute). That would avoid confusion such as what we saw here.The more interesting question is what to do with
If the body of the function doesn't do anything const-unstable, it seems fine to just treat this as const-stable, maybe? Or do we want to still force people to add an explicit
rustc_const_stable
? I am not sure I see the value in that -- the dangerous case is when that function calls some const-unstable things, such as const-unstable intrinsics. That will still requirerustc_allow_const_fn_unstable
, and that is the point where we have to ensure we get involved.To avoid any kind of accidental changes, we probably want to start by making it an error for a
const fn
to carrystable
orunstable
without also carryingrustc_const_stable
orrustc_const_unstable
. I had a brief look at the stability system but couldn't find an obvious place to add such a lint; so if someone has an idea please let me know. :)And speaking of
rustc_allow_const_fn_unstable
-- I feel like the way we use that also may need to change. A lot of the current uses of that attribute are a case of "some public stable function is implemented using still-unstable functions" -- but the still-unstable functions are not actually doing anything funky const-wise. They could be markedrustc_const_stable
, meaning "wg-const-eval approved their use on stable", even while t-libs-api still debates whether the API itself (independent of itsconst
usage) should exist on stable.Cc @rust-lang/wg-const-eval
The text was updated successfully, but these errors were encountered: