Impl Try for Option #42526

huntiep · 2017-06-08T03:58:32Z

This is part of #31436.

rust-highfive · 2017-06-08T03:58:44Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

kennytm · 2017-06-08T05:20:38Z

src/libcore/option.rs

+/// The `Option` type. See [the module level documentation](index.html) for more.
+#[unstable(feature = "try_trait", issue = "42327")]
+#[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
+pub struct Missing;


Wrong documentation?

Yes, I needed something there in order to compile and forgot to change it. I'm not sure what to replace it with; maybe The equivalent of Option::None for a Result type.?

scottmcm · 2017-06-08T06:35:41Z

This is exciting, and applying right after branching for release is probably the best option we have for insta-stable things like this. (This will allow ? on Option without a feature gate, right?)

Something I didn't want to push in the RFC discussion, but thought interesting: what about a None type (instead of Missing) for <Option<T> as Try>::Error? Then at the type level it's also "an option is either a T or None". Sample implementation: https://doc.rust-lang.org/nightly/unstable-book/library-features/try-trait.html

That's intentionally non-constructible for now, since what I think it ought to be is type None = Option<!>; so that let _: None = None; would be valid, and more importantly that a throw sugar (in auto-wrapping) would allow throw None; and return 4; (paralleling return None; and return Some(4);).

Though I guess the type will stay unstable for a while, so it doesn't matter for now...

oli-obk · 2017-06-08T10:07:04Z

src/libcore/tests/option.rs

+    assert_eq!(try_option_none(), None);
+
+    fn try_option_ok() -> Result<u8, Missing> {
+        let val = Ok(1)?;


This is not going through the Option. I already works now... Maybe you meant to use Some here?

oli-obk · 2017-06-08T10:07:38Z

src/libcore/tests/option.rs

+    assert_eq!(try_option_ok(), Ok(1));
+
+    fn try_option_err() -> Result<u8, Missing> {
+        let val = Err(Missing)?;


And None here

oli-obk · 2017-06-08T10:10:01Z

src/libcore/tests/result.rs

+    assert_eq!(try_result_none(), None);
+
+    fn try_result_ok() -> Result<u8, u8> {
+        let val = Ok(1)?;


This is also nothing new... maybe change it into a compile-fail test by using Some/None and triggering a compilation error

I didn't see any tests for Result's Try implemenation, but if they exist I can remove these tests.

alexcrichton · 2017-06-08T14:17:31Z

r? @aturon

Also cc @rust-lang/lang, especially @scottmcm's comment where I think this is insta-stable

nikomatsakis · 2017-06-09T21:49:18Z

I think one way to prevent it from being insta-stable would be to make it #[cfg(nightly)], right? Have we rejected this path for some reason?

I am open to bikeshedding the name of Missing -- I agree it doesn't feel right to me. None might be better, though if we ever get types for variants, that might be .. surprising?

MoSal · 2017-06-10T04:54:22Z

Maybe ErrNone or TryNone or TryErrNone.

kennytm · 2017-06-10T06:23:33Z

@nikomatsakis Previous discussion https://internals.rust-lang.org/t/setting-cfg-nightly-on-nightly-by-default/1893

nikomatsakis · 2017-06-13T17:46:36Z

@kennytm well that was more about a public "cfg", but yeah apparently we don't have #[cfg(nightly)] even without rustc. For some reason, I thought we did. Regardless, it's not a great suggestion; it wouldn't require any opt-in, which is really what you want.

huntiep · 2017-06-13T21:52:26Z

I also like ErrNone over Missing. I just followed the impl outlined in the RFC.

At this point what do I need to do?

nikomatsakis · 2017-06-14T21:53:56Z

I think we should settle on the name -- I am not 100% sure when we should merge this RFC though. The insta-stable thing bothers me, but I don't have a good idea what else to do about it.

nikomatsakis · 2017-06-14T21:54:51Z

@rust-lang/lang @rust-lang/libs -- anybody care to "weigh in" on the name of the "error type" to use in the Try impl for Option? The RFC said Missing, but ErrNone has been proposed as an alternative. Some newtype is needed, at least.

kennytm · 2017-06-14T22:08:05Z

If we follow the naming practice in libstd, it should be ***Error (e.g. NoneError) instead of ErrNone.

withoutboats · 2017-06-14T23:05:34Z

What's the reason not to use ()?

kennytm · 2017-06-14T23:51:02Z

@withoutboats rust-lang/rfcs#1859 explained why the error must be a dedicated type (to prevent accidentally ?-returning an Option<T> as Result<T, ()> and vice-versa).

huntiep · 2017-06-15T04:53:39Z

I think NoneError is fine, as long as it is well documented. Right now Missing is documented as

/// The equivalent of `Option::None` for a `Result::Err`.

Any thoughts on how to better document this, regardless of what the final name is?

alexcrichton · 2017-06-15T14:24:30Z

Ergonomically at least this seems most likely to arise in something like:

impl From<Missing> for MyErrorType

(if at all). That way you could option? in functions that return Result. In that sense From<Missing> does indeed seem a little ambiguous, but either From<ErrNone> or From<NoneError> are both more clear. Note, though that From<option::Missing> is also pretty clear.

sfackler · 2017-06-15T16:03:13Z

WasNone is another naming option.

nikomatsakis · 2017-06-15T18:24:04Z

@withoutboats

What's the reason not to use ()?

The feeling was that () is not sufficiently precise. In particular, one could readily imagine there being other "option-like" types that might also default to use (), and this would allow interconversion between them when you didn't really want to allow that. For example:

enum List<T> {
    Nil,
    Cons(T, Box<List<T>>),
}

Imagine that I implemented Try for List and made the "error" case be () (because it seemed like a reasonable default). Granted, this is probably not the best example, though it's not so uncommon for "lists" to be a monad, so I could imagine someone doing it. Anyway, this led to the recommendation to use a newtype, so that the intention is more explicit.

nikomatsakis · 2017-06-15T18:26:34Z

👍 for NoneError. I like that. I think the documentation should probably be something like:

"The error type that results from applying the try operator (?) to a None value. If you wish to allow x? (where x is an Option<T>) to be converted into your error type, you can implement impl From<NoneError> for YourErrorType. In that case, x? within a function that returns Result<_, YourErrorType> will translate a None value into an Err result."

nikomatsakis · 2017-09-28T13:12:37Z

@huntiep I took the liberty of rebasing for you.

huntiep · 2017-09-29T06:43:43Z

@nikomatsakis I'm sorry, I missed that part of your last comment. For future reference, can you briefly explain what you meant by rebase?

shepmaster · 2017-09-29T13:35:14Z

@huntiep it refers to git rebase. You can do git rebase --help or check out some pages like this one to learn more. Many times it's done to "clean up" a branch before merging by removing "intermediate" work that's not important to track forever, or to resolve any merge conflicts.

shepmaster · 2017-09-29T13:35:56Z

@nikomatsakis did you mean to review at bors?

aturon · 2017-09-29T17:22:25Z

@bors: r=nikomatsakis

bors · 2017-09-29T17:22:26Z

📌 Commit e30d92b has been approved by nikomatsakis

bors · 2017-09-29T20:09:41Z

⌛ Testing commit e30d92b with merge 6f87d20...

Impl Try for Option This is part of #31436.

bors · 2017-09-29T22:35:17Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 6f87d20 to master...

@bluss

Short-circuiting internal iteration with Iterator::try_fold & try_rfold These are the core methods in terms of which the other methods (`fold`, `all`, `any`, `find`, `position`, `nth`, ...) can be implemented, allowing Iterator implementors to get the full goodness of internal iteration by only overriding one method (per direction). Based off the `Try` trait, so works with both `Result` and `Option` (:tada: #42526). The `try_fold` rustdoc examples use `Option` and the `try_rfold` ones use `Result`. AKA continuing in the vein of PRs #44682 & #44856 for more of `Iterator`. New bench following the pattern from the latter of those: ``` test iter::bench_take_while_chain_ref_sum ... bench: 1,130,843 ns/iter (+/- 25,110) test iter::bench_take_while_chain_sum ... bench: 362,530 ns/iter (+/- 391) ``` I also ran the benches without the `fold` & `rfold` overrides to test their new default impls, with basically no change. I left them there, though, to take advantage of existing overrides and because `AlwaysOk` has some sub-optimality due to #43278 (which 45225 should fix). If you're wondering why there are three type parameters, see issue #45462 Thanks for @bluss for the [original IRLO thread](https://internals.rust-lang.org/t/pre-rfc-fold-ok-is-composable-internal-iteration/4434) and the rfold PR and to @cuviper for adding so many folds, [encouraging me](#45379 (comment)) to make this PR, and finding a catastrophic bug in a pre-review.

rust-highfive assigned alexcrichton Jun 8, 2017

kennytm reviewed Jun 8, 2017

View reviewed changes

oli-obk reviewed Jun 8, 2017

View reviewed changes

nikomatsakis mentioned this pull request Jun 8, 2017

Tracking issue for ? operator and try blocks (RFC 243, question_mark & try_blocks features) #31436

Open

12 tasks

rust-highfive assigned aturon and unassigned alexcrichton Jun 8, 2017

alexcrichton added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 8, 2017

frewsxcv added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jun 11, 2017

arielb1 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 13, 2017

huntiep added 3 commits September 27, 2017 17:56

Add docs for Missing, correct Option's Try test

8f63e8d

Rename option::Missing to NoneError

28996db

Add UI tests

e30d92b

aidanhs added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 28, 2017

nikomatsakis force-pushed the try_opt branch from 10fc9fb to e30d92b Compare September 28, 2017 13:12

nikomatsakis approved these changes Sep 28, 2017

View reviewed changes

bors added a commit that referenced this pull request Sep 29, 2017

Auto merge of #42526 - huntiep:try_opt, r=nikomatsakis

6f87d20

Impl Try for Option This is part of #31436.

bors merged commit e30d92b into rust-lang:master Sep 30, 2017

topecongiro mentioned this pull request Oct 5, 2017

Replace try_opt! with ? rust-lang/rustfmt#2034

Closed

This was referenced Oct 5, 2017

Fix unused warning in util.rs for Windows rust-dev-tools/rls-analysis#94

Closed

Perform some housekeeping rust-dev-tools/rls-analysis#95

Merged

scottmcm mentioned this pull request Oct 28, 2017

Short-circuiting internal iteration with Iterator::try_fold & try_rfold #45595

Merged

bluss mentioned this pull request Oct 28, 2017

Updated Release notes for 1.22.0 #45454

Merged

GabrielMajeri mentioned this pull request Nov 4, 2017

Replace try_opt macro with ? nabijaczleweli/rust-embed-resource#7

Merged

Emilgardis mentioned this pull request Nov 28, 2017

impl Fail for NoneError? rust-lang-deprecated/failure#59

Closed

rillian mentioned this pull request Jan 12, 2018

Crate failed to build rust-lang/docs.rs#23

Closed

Timidger mentioned this pull request Mar 12, 2018

Compile error. Using ? on Option<T> way-cooler/way-cooler#506

Closed

Freaky mentioned this pull request Sep 7, 2018

Tidy Result/Option use staktrace/mailparse#29

Merged

Coder-256 mentioned this pull request Aug 12, 2019

why havn't implemented Error trait for std::option::NoneError ? #46871

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Impl Try for Option #42526

Impl Try for Option #42526

huntiep commented Jun 8, 2017

rust-highfive commented Jun 8, 2017

kennytm Jun 8, 2017

huntiep Jun 8, 2017

scottmcm commented Jun 8, 2017

oli-obk Jun 8, 2017

oli-obk Jun 8, 2017

oli-obk Jun 8, 2017

huntiep Jun 8, 2017

alexcrichton commented Jun 8, 2017

nikomatsakis commented Jun 9, 2017

MoSal commented Jun 10, 2017

kennytm commented Jun 10, 2017

nikomatsakis commented Jun 13, 2017

huntiep commented Jun 13, 2017

nikomatsakis commented Jun 14, 2017

nikomatsakis commented Jun 14, 2017

kennytm commented Jun 14, 2017

withoutboats commented Jun 14, 2017

kennytm commented Jun 14, 2017

huntiep commented Jun 15, 2017

alexcrichton commented Jun 15, 2017

sfackler commented Jun 15, 2017

nikomatsakis commented Jun 15, 2017

nikomatsakis commented Jun 15, 2017

nikomatsakis commented Sep 28, 2017

huntiep commented Sep 29, 2017

shepmaster commented Sep 29, 2017

shepmaster commented Sep 29, 2017

aturon commented Sep 29, 2017

bors commented Sep 29, 2017

bors commented Sep 29, 2017

bors commented Sep 29, 2017

Impl Try for Option #42526

Impl Try for Option #42526

Conversation

huntiep commented Jun 8, 2017

rust-highfive commented Jun 8, 2017

kennytm Jun 8, 2017

Choose a reason for hiding this comment

huntiep Jun 8, 2017

Choose a reason for hiding this comment

scottmcm commented Jun 8, 2017

oli-obk Jun 8, 2017

Choose a reason for hiding this comment

oli-obk Jun 8, 2017

Choose a reason for hiding this comment

oli-obk Jun 8, 2017

Choose a reason for hiding this comment

huntiep Jun 8, 2017

Choose a reason for hiding this comment

alexcrichton commented Jun 8, 2017

nikomatsakis commented Jun 9, 2017

MoSal commented Jun 10, 2017

kennytm commented Jun 10, 2017

nikomatsakis commented Jun 13, 2017

huntiep commented Jun 13, 2017

nikomatsakis commented Jun 14, 2017

nikomatsakis commented Jun 14, 2017

kennytm commented Jun 14, 2017

withoutboats commented Jun 14, 2017

kennytm commented Jun 14, 2017

huntiep commented Jun 15, 2017

alexcrichton commented Jun 15, 2017

sfackler commented Jun 15, 2017

nikomatsakis commented Jun 15, 2017

nikomatsakis commented Jun 15, 2017

nikomatsakis commented Sep 28, 2017

huntiep commented Sep 29, 2017

shepmaster commented Sep 29, 2017

shepmaster commented Sep 29, 2017

aturon commented Sep 29, 2017

bors commented Sep 29, 2017

bors commented Sep 29, 2017

bors commented Sep 29, 2017