-
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
Tracking issue for const Option
functions
#67441
Comments
Make some Option methods const Tracking issue: rust-lang#67441 Constantify the following methods of `Option`: - `as_ref` - `is_some` - `is_none` - `iter` (not sure about this one, but it is possible, and will be useful when const traits are a thing) cc @rust-lang/wg-const-eval @rust-lang/libs
Make some Option methods const Tracking issue: rust-lang#67441 Constantify the following methods of `Option`: - `as_ref` - `is_some` - `is_none` - `iter` (not sure about this one, but it is possible, and will be useful when const traits are a thing) cc @rust-lang/wg-const-eval @rust-lang/libs
…=oli-obk Make `Option::unwrap` unstably const This is lumped into the `const_option` feature gate (rust-lang#67441), which enables a potpourri of `Option` methods. cc @rust-lang/wg-const-eval r? @oli-obk
Stabilize some Option methods as const Stabilize the following methods of `Option` as const: - `is_some` - `is_none` - `as_ref` These methods are currently const under the unstable feature `const_option` (tracking issue: rust-lang#67441). I believe these methods to be eligible for stabilization because of the stabilization of rust-lang#49146 (Allow if and match in constants) and the trivial implementations, see also: [PR#75463](rust-lang#75463). Related: rust-lang#76225
Stabilize some Option methods as const Stabilize the following methods of `Option` as const: - `is_some` - `is_none` - `as_ref` These methods are currently const under the unstable feature `const_option` (tracking issue: rust-lang#67441). I believe these methods to be eligible for stabilization because of the stabilization of rust-lang#49146 (Allow if and match in constants) and the trivial implementations, see also: [PR#75463](rust-lang#75463). Related: rust-lang#76225
Yes for constantifying However, as per https://doc.rust-lang.org/nightly/src/core/option.rs.html,
Since that is not specific to |
@peter-kehl the tracking issue for panicking in constants is #51999 |
FYI anyone looking at I wonder if it would be feasible for the compiler to allow use of |
@davidhewitt Given that neither const trait impls nor const trait bounds are usable on stable, it would be quite unintuitive if this were. Even on nightly, const traits have yet to be RFC accepted. |
Sorry, I typo'd above - I meant to say only allow types which don't We probably wouldn't want this in the function signature (should just be TBH it sounds messy and slightly leaks information about the function implementation, so I'm unconvinced it's worth the effort. Just musing of a way to allow some forms of const |
Yeah, I figured it was a typo and responded accordingly. I still think it would be awkward to have this magically work for some types but not others, especially if this isn't in the function signature. I'd much rather wait for const trait impls to be RFC approved and land on stable, as that would allow way more than just this. Just look at the blockers on #82814 and realize that having const trait impls would allow ~80% of them (just guessing, I haven't bothered to actually calculate a percentage). |
If/when #51999 is stabilized, |
@jhpratt |
Can @9999years add these to the list at the top? |
…-replace, r=joshtriplett const fn for option copied, take & replace Tracking issue: [rust-lang#67441](rust-lang#67441) Adding const fn for the copied, take and replace method of Option. Also adding necessary unit test. It's my first contribution so I am pretty sure I don't know what I'm doing but there's a first for everything!
…-replace, r=joshtriplett const fn for option copied, take & replace Tracking issue: [rust-lang#67441](rust-lang#67441) Adding const fn for the copied, take and replace method of Option. Also adding necessary unit test. It's my first contribution so I am pretty sure I don't know what I'm doing but there's a first for everything!
Was there any actual blocker to stabilising |
Precise live drops (or whatever it's called) is the sole blocker to my knowledge. |
AFAICT, little progress were made since #73255 (comment) so I guess stabilization is likely going to take some time. |
Can we make unwrap_or, ok_or, and, filter, or, or_else, xor, transpose, flatten stable? Those functions don't seem to have any blockers. |
|
forgot the signature of filter, sorry— i didnt realize that the const precise live drops applied to all of the functions, my bad |
@rust-lang/wg-const-eval how bad of an idea would it be to stabilize at least The blocking concern for |
Yea that's fine. We will always find a way to support these |
Ah, it's not so easy... EDIT: #129507 fixes that. Once it is in beta, we can proceed with stabilizing at least |
…_drops, r=wesleywiser make it possible to enable const_precise_live_drops per-function This makes const_precise_live_drops work with rustc_allow_const_fn_unstable so that we can stabilize individual functions that rely on const_precise_live_drops. The goal is that we can use that to stabilize some of rust-lang#67441 without having to stabilize const_precise_live_drops.
Rollup merge of rust-lang#129507 - RalfJung:per-fn-const_precise_live_drops, r=wesleywiser make it possible to enable const_precise_live_drops per-function This makes const_precise_live_drops work with rustc_allow_const_fn_unstable so that we can stabilize individual functions that rely on const_precise_live_drops. The goal is that we can use that to stabilize some of rust-lang#67441 without having to stabilize const_precise_live_drops.
I've cleaned up and updated the list -- some things were listed but they were not even unstably const (such as |
…ingjubilee remove 'const' from 'Option::iter' This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone. The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue. Cc rust-lang#67441
…ingjubilee remove 'const' from 'Option::iter' This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone. The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue. Cc rust-lang#67441
…ingjubilee remove 'const' from 'Option::iter' This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone. The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue. Cc rust-lang#67441
…ingjubilee remove 'const' from 'Option::iter' This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone. The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue. Cc rust-lang#67441
…ingjubilee remove 'const' from 'Option::iter' This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone. The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue. Cc rust-lang#67441
Rollup merge of rust-lang#130087 - RalfJung:option-const-iter, r=workingjubilee remove 'const' from 'Option::iter' This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone. The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue. Cc rust-lang#67441
remove 'const' from 'Option::iter' This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone. The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue. Cc rust-lang/rust#67441
…rieb move Option::unwrap_unchecked into const_option feature gate That's where `unwrap` and `expect` are so IMO it makes more sense to group them together. Part of rust-lang#91930, rust-lang#67441
Rollup merge of rust-lang#130118 - RalfJung:unwrap_unchecked, r=Noratrieb move Option::unwrap_unchecked into const_option feature gate That's where `unwrap` and `expect` are so IMO it makes more sense to group them together. Part of rust-lang#91930, rust-lang#67441
Current candidates with
feature = const_option
:See also the meta-tracking issue for const fns, #57563.
Blocked on:
&mut T
in const contexts (const_mut_refs) #57349Also see the corresponding
Result
tracking issue: #82814.The text was updated successfully, but these errors were encountered: