-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add LazyCell::into_inner #106152
Add LazyCell::into_inner #106152
Conversation
r? @scottmcm (rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
@rustbot label +T-libs-api -T-libs |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Prior art from the crate: https://docs.rs/once_cell/1.16.0/src/once_cell/lib.rs.html#713-719
|
@matklad Seems reasonable, done. |
For consistency, this should probably be added to |
Sounds reasonable, done. |
☔ The latest upstream changes (presumably #106193) made this pull request unmergeable. Please resolve the merge conflicts. |
I don't think I'm a good person to make even a nightly decision about this API, so flipping over to r? rust-lang/libs-api |
library/core/src/cell/lazy.rs
Outdated
/// assert_eq!(&*lazy, "HELLO, WORLD!"); | ||
/// assert_eq!(LazyCell::into_inner(lazy).ok(), Some("HELLO, WORLD!".to_string())); | ||
/// ``` | ||
#[unstable(feature = "once_cell", issue = "74465")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this maybe have a separate feature gate? When we'll be stabilizing once cell we'll want to first stabilize some sort of minimal API and only then stabilize other methods...
#[unstable(feature = "once_cell", issue = "74465")] | |
#[unstable(feature = "once_cell_into_inner", issue = "74465")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it goes the other way around: #105587
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's just because we didn't split originally though?.. It's always easier to stabilize small parts of the API and it's also easier when you don't have to change the gate before stabilizing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but why should this method be stabilized separately from the rest of Lazy*? That seems like a decision that can be made when we're actually ready to stabilize the Lazy variants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's just generally a good idea to have small feature gates, stabilizing multiple at the same time is a lot simpler and more clear than splitting one into multiple and stabilizing a subset. This method doesn't look essential, so I don't think it is likely it will be included in the first stabilization.
I find returning a If there was an explicit decision to not expose the uninitialized state then I think we should continue doing this and have |
That would make this API mostly useless since the point is to say "if something was initialized, let me do X with it." In my case X is flushing pending tasks from a lazily created thread pool. I do agree that using a result is super weird. Maybe we should create our own
Maybe lazy should have this too? The crate has it too: https://docs.rs/once_cell/latest/once_cell/sync/struct.Lazy.html#method.get |
Thanks! I added a comment mentioning the feature: #109736 (comment) |
@SUPERCILEX awesome! Quick note - the gate name |
@tgross35 do you have bors r+ perms? I can rename it to |
I do not, but I think it can just be renamed in a separate PR if it's needed |
Sounds good, I'll leave it be then. |
Add LazyCell::into_inner This enables uses cases that need to extract the evaluated value and do something owned with it.
Add LazyCell::into_inner This enables uses cases that need to extract the evaluated value and do something owned with it.
Add LazyCell::into_inner This enables uses cases that need to extract the evaluated value and do something owned with it.
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
Finished benchmarking commit (fdeef3e): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
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.
|
Wat? I don't see how this could possibly be related. All this PR does is add a method that isn't used anywhere. |
The usual keccak/cranelift-codegen bimodality, nothing to worry about. |
Whew, thanks! |
Agreed, @rustbot label: +perf-regression-triaged |
This enables uses cases that need to extract the evaluated value and do something owned with it.