Hi everyone
I get a puzzled when understand ~const
constraint in method Option.map_or
. the source code as follow
pub const fn map_or<U, F>(self, default: U, f: F) -> U
where
F: ~const FnOnce(T) -> U,
F: ~const Drop,
U: ~const Drop,
{
match self {
Some(t) => f(t),
None => default,
}
}
Can anyone give me some tip or suggestion about it ?
1 Like
You can ignore the “~const
” part on the FnOnce
bound, and you can ignore the “…: ~const Drop
” bounds entirely (just how they aren’t appearing in the documentation either). This syntax is part of an in-development unstable language feature.
opened 12:37AM - 02 Jan 20 UTC
A-traits
T-lang
A-const-fn
C-tracking-issue
A-const-eval
F-const_trait_impl
This is the primary tracking issue for rust-lang/rfcs#2632.
The current RFC t… ext can be found at https://internals.rust-lang.org/t/pre-rfc-revamped-const-trait-impl-aka-rfc-2632/15192
This RFC has not yet been accepted. It is being implemented on a provisional basis to [evaluate the potential fallout](https://github.com/rust-lang/rfcs/pull/2632#issuecomment-567699174).
cc https://github.com/rust-lang/rust/issues/57563
The feature gate is `const_trait_impl`
### Open issues
* [x] #88155
* [x] [this test](https://github.com/rust-lang/rust/blob/cb406848eccc3665dfadb241d94fe27137bd0dcb/src/test/ui/rfc-2632-const-trait-impl/call-generic-method-nonconst.rs) shows we can currently still call a `const fn` with a `Trait` bound even if the concrete type does not implement `const Trait`, but just `Trait`. This will fail later during evaluation. Some related discussion can be found in https://github.com/rust-lang/rust/pull/79287#discussion_r528341238
* [x] There are no tests for *using* a `const impl` without *defining* one without the feature gate enabled. This should be added before any `impl const` is added to the standard library.
* [x] We need some tests and probably code around `#[rustc_const_stable]` and `#[rustc_const_unstable]` so we can properly stabilize (or not) the constness of impls in the standard library
* [x] #79450 shows that with default function bodies in the trait declaration, we can cause non-const functions to exist in `impl const Trait` impls by leaving out these default functions
* [ ] We need to determine the final syntax for `~const`. (In the interim, we may want to switch this to use a `k#provisional_keyword` or similar.)
* [ ] If we need `#[default_method_body_is_const]`, determine the syntax for it instead of existing as an attribute
**When stabilizing: compiler changes are required**:
* [ ] Error against putting `rustc_const_unstable` attribute on `const` `impl`s as they are now insta-stable.
* [ ] Treat `default_method_body_is_const` bodies and `const` `impl` bodies as `stable` `const fn` bodies. We need to prevent accidentally stabilizing an implementation that uses unstable lang/lib `const fn` features.
* [ ] Change Rustdoc to display `~const` bounds or what syntax we decided it to be.
On stable Rust, this method is essentially just
impl<T> Option<T> {
pub fn map_or<U, F>(self, default: U, f: F) -> U
where
F: FnOnce(T) -> U,
{
match self {
Some(t) => f(t),
None => default,
}
}
}
3 Likes