-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-result-optionArea: Result and Option combinatorsArea: Result and Option combinatorsB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCLibs-SmallLibs issues that are considered "small" or self-containedLibs issues that are considered "small" or self-containedLibs-TrackedLibs issues that are tracked on the team's project board.Libs issues that are tracked on the team's project board.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.disposition-closeThis PR / issue is in PFCP or FCP with a disposition to close it.This PR / issue is in PFCP or FCP with a disposition to close it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.
Description
impl<T: fmt::Debug> Option<T> {
pub fn expect_none(self, msg: &str);
pub fn unwrap_none(self);
}
Steps:
- Merge the implementation (Add Option::expect_none(msg) and unwrap_none() #62596)Stabilization PRUpdate the
must_use
message onis_none
(per Add messages toOption
's andResult
'smust_use
annotation foris_*
#62431 (review))To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
stanislav-tkach, museun, lokegustafsson, sourcefrog, Urhengulas and 18 moretrevyn, Ltrlg, jaymody, Scripter17 and finnbear
Metadata
Metadata
Assignees
Labels
A-result-optionArea: Result and Option combinatorsArea: Result and Option combinatorsB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCLibs-SmallLibs issues that are considered "small" or self-containedLibs issues that are considered "small" or self-containedLibs-TrackedLibs issues that are tracked on the team's project board.Libs issues that are tracked on the team's project board.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.disposition-closeThis PR / issue is in PFCP or FCP with a disposition to close it.This PR / issue is in PFCP or FCP with a disposition to close it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
jfrimmel commentedon Oct 2, 2019
cuviper commentedon Oct 2, 2019
jfrimmel commentedon Oct 2, 2019
cuviper commentedon Apr 20, 2020
I guess it could use more in-repo callers? I do see that
rustc_middle
andrustc_mir
are usingexpect_none
, at least. Grepping forassert.*is_none
shows a lot more possibilities, but maybe some of those would not like the added code toDebug
the value in the panic message.aclysma commentedon May 16, 2020
I'd love to see this go to stable.. I'm having to do this:
And I'd much rather do
dtolnay commentedon Jun 9, 2020
In the stabilization PR it was raised that
&self
may be more appropriate and flexible in these signatures thanself
. Do potential users here have a preference for either?RustyYato commentedon Jun 9, 2020
You can use
as_ref
if you need a reference. Also, we should be consistent between our functions (Option::unwrap
).136 remaining items
SOF3 commentedon Nov 25, 2022
The problem is that this issue is fundamentally an XY problem, where the real problem is the lack of postfix macros but we tried to solve this problem by bloating the standard library instead.
RalfJung commentedon Nov 25, 2022
SOF3 commentedon Nov 25, 2022
@RalfJung yes, I think
unwrap
andexpect
are bloat as well. They should have simply beenRollup merge of #82764 - m-ou-se:map-try-insert, r=Amanieu
zdivelbiss commentedon Apr 7, 2023
This statement doesn't really make any sense. You aren't unwrapping the
None
, you're unwrapping theOption
, which may or may not containSome
thing. Unless the libs team or someone else explicitly specifies what 'unwrap' to be consistent with that argument, the 🎁 analogy used earlier holds: unwrapping a present and finding nothing was still unwraping the present.I'm skeptical of this at its face value. The notion of
unwrap_
is fundamentally the concept of "unwrap this container, expect this valuedness, then return what was inside":unwrap()
->unwrap and expect Some()/Ok(), and return the value
unwrap _err()
->unwrap Err(), and return the value
unwrap_none()
->unwrap None, and return the value (in this case, nothing, which has a value in Rust!)
This is simply not ergonomically consistent with how one expects to assert the valuedness of the container enums. Unless there are plans to deprecate the panicking
unwrap_
APIs, then this semantic inconsistency will continue to draw new users to this issue, only to be disappointed by unclear and inconsistent logic from the rust teams.This seems like skirting around the reality that the expectation of a semantic way to inline-assert the valuedness of a container has already been proposed in this issue. You certainly can introduce the function discussed in this thread as an entirely new unwrapping API separate from the existing unwrapping APIs, but it feels like arbitrarily beating around the bush of this issue. Really, this is functionally another inline syntax for
Option::ok_or().unwrap_err()
.Overall, reading this, I wasn't particularly satisfied with the responses, justifications, or in general the way this issue was handled. There was next to no communication while the issue was being reviewed, followed by subjective arguments, followed (finally) by an actual discussion of the logical reasoning of the libs team.
It really just seems like the team that voted on this doesn't like the idea of unwrapping an empty 🎁.
buzmeg commentedon Apr 17, 2023
Quoting @SOF3
Which would be fine, except that 5 years on we don't have a solution for X OR Y. And none of the alternatives mentioned to solve this have moved even slightly over 5 years. And, if postfix macros didn't get resolved given their usefulness for "async" which everybody on the core team was totally obsessed with, they are never going to move.
So, I'm so glad you maintained your vaunted "language purity", but, in the meantime, users of the language are still stuck exactly where they started.
That's fine. Many of us can take a hint and understand that it is time to move on from Rust.
mankinskin commentedon Apr 17, 2023
To contrast, I find there is value in a clean code base and principled design. But I think pragmatism is one of the most important principles which should drive language design. And I personally don't really have any validated reasons on my list about why
unwrap_none
orexpect_none
would be bad to have. If there is any reason why the existence of these functions could reduce the quality of the Rust language, then maybe we should start talking about those instead of why it might be a good idea to have these. They are obviously useful, so if there are no reasons why this should be blocked it should simply be added to a library and eventually stabilized.m-ou-se commentedon Apr 18, 2023
Sure.
To unwrap the
Option
, we already have a method:.unwrap()
. In anOption::None
, there is nothing to unwrap, so it panicks..unwrap()
is about getting the contents of theSome
out. But.unwrap_none()
isn't about getting the contents of theNone
out, because there are none. Sure, you can represent that as()
, but if you want a()
, you don't need to call this method. The only reason you'd ever call.unwrap_none()
is as an assertion, a conditional panic, not as a way to access a value. So, it'd basically be a.panic_if_some()
or.assert_none()
.So then the question is whether we want such methods. I don't think we do, because we also don't have anything like
i32::assert_nonzero()
,bool::panic_if_false()
, orVec::unwrap_empty()
, and so on. All of those assertions you'd write using an assert macro or a panic inside an if. I don't think there is enough reason to giveOption::is_none()
special treatment.I don't think Rust is very "pure". I also don't think users are "stuck". There are many simple ways to express a check for
None
, so I doubt this is really a blocker for anyone. Maybe there's even a crate with an extension trait to add.panic_if_…()
to various common types.Many reasons have been given in this thread. I'm not sure what I can add at this point without just repeating things that have already been said.
m-ou-se commentedon Apr 18, 2023
As I highlighted here, we're all just volunteers working on the standard library next to many other tasks, so while we'll try our best to communicate everything as clearly as possible, it sometimes takes longer than you might hope for.
I'm afraid that API design will always be based on subjective arguments. There's no objective right or wrong way to design a library.
I'm not sure what you expect from us at this point. Many arguments have been given and thoroughly explained over the past few years, and it just seems like we're going in circles now. :/
pronebird commentedon Jun 29, 2024
The unexpected. I mean, literally, the
unexpect(<msg>)
to mirror already availableexpect()
feat: Add is_none
feat: Add is_none
feat: Add is_none
Option::todo
andResult::todo
rust-lang/rfcs#3706