-
Notifications
You must be signed in to change notification settings - Fork 12.1k
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
Stabilise inline_const #104087
Stabilise inline_const #104087
Conversation
r? @JohnTitor (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in src/tools/clippy cc @rust-lang/clippy Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
This comment has been minimized.
This comment has been minimized.
I think this needs FCP, cc @rust-lang/lang |
@rustbot label: -T-libs +T-lang +I-lang-nominated |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Thanks for the report! It looks like the current state is enough to allow this to work: pub fn create_none_array<T, const N: usize>() -> [Option<T>; N] {
[const { None }; N]
} which is the use that keeps coming up on URLO. And this also keeps coming up (1 2) on IRLO as needed (or at least wanted) for various things. So let's do it! @rfcbot fcp merge cc Tracking Issue #76001, which also covers patterns so isn't closed by this PR. |
This comment was marked as outdated.
This comment was marked as outdated.
(Sorry, compiler folks. One day I'll remember to check the labels before kicking off an FCP.) |
If you do a sync, make sure to go through all PRs in the queue and r- them by hand if they previously failed. A sync re-adds all previously failed PRs unless they get manually r-'d. |
@bors retry |
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
Finished benchmarking commit (7bb4f08): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 674.062s -> 672.117s (-0.29%) |
@rustbot label +relnotes |
Stabilisation Report
Summary
This PR will stabilise
inline_const
feature in expression position.inline_const_pat
is still unstable and will not be stabilised.The feature will allow code like this:
which is roughly desugared into
This feature is from rust-lang/rfcs#2920 and is tracked in #76001 (the tracking issue should not be closed as it needs to track inline const in pattern position). The initial implementation is done in #77124.
Difference from RFC
There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content within it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. #89964). The inference is implemented in #89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body.
This allows code like:
Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in #96557.
This allows code like:
This enhancement also makes inline const usable as static asserts:
Documentation
Reference: rust-lang/reference#1295
Unresolved issues
We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation:
const {}
behaves similar toasync {}
but not to{}
andunsafe {}
(they are treated asExpressionWithoutBlock
rather thanExpressionWithBlock
): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453Tests
There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const