-
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
Mention Result<!, E> in never docs. #49988
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -112,6 +112,8 @@ mod prim_bool { } | |
/// | ||
/// # `!` and generics | ||
/// | ||
/// ## Infalliable errors | ||
/// | ||
/// The main place you'll see `!` used explicitly is in generic code. Consider the [`FromStr`] | ||
/// trait: | ||
/// | ||
|
@@ -140,9 +142,59 @@ mod prim_bool { } | |
/// [`Ok`] variant. This illustrates another behaviour of `!` - it can be used to "delete" certain | ||
/// enum variants from generic types like `Result`. | ||
/// | ||
/// ## Infinite loops | ||
/// | ||
/// While [`Result<T, !>`] is very useful for removing errors, `!` can also be used to removed | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Typo: removed -> remove There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. same |
||
/// successes as well. If we think of [`Result<T, !>`] as "if this function returns, it has not | ||
/// errored," we get a very intuitive idea of [`Result<!, E>`] as well: if the function returns, it | ||
/// *has* errored. | ||
/// | ||
/// For example, consider the case of a simple web server, which can be simplified to: | ||
/// | ||
/// ```ignore (hypothetical-example) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've never seen this notation, does this work? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I actually copied it from an example earlier in the file, so, I assume so? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It doesn't do anything. It's recognized as non-rust code. That's pretty much all. |
||
/// loop { | ||
/// let (client, request) = get_request().expect("disconnected"); | ||
/// let response = request.process(); | ||
/// response.send(client); | ||
/// } | ||
/// ``` | ||
/// | ||
/// Currently, this isn't ideal, because we simply panic whenever we fail to get a new connection. | ||
/// Instead, we'd like to keep track of this error, like this: | ||
/// | ||
/// ```ignore (hypothetical-example) | ||
/// loop { | ||
/// match get_request() { | ||
/// Err(err) => break err, | ||
/// Ok((client, request)) => { | ||
/// let response = request.process(); | ||
/// response.send(client); | ||
/// }, | ||
/// } | ||
/// } | ||
/// ``` | ||
/// | ||
/// Now, when the server disconnects, we exit the loop with an error instead of panicking. While it | ||
/// might be intuitive to simply return the error, we might want to wrap it in a [`Result<!, E>`] | ||
/// instead: | ||
/// | ||
/// ```ignore (hypothetical-example) | ||
/// fn server_loop() -> Result<!, ConnectionError> { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I really like this example 👍 A thought: with #49162, it could even be fn main() -> Result<!, ConnectionError> Also, I think the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My main reasoning for not making this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd prefer to leave off the Ok, but I can agree that this being not main makes a lot of sense There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll leave off the |
||
/// Ok(loop { | ||
/// let (client, request) = get_request()?; | ||
/// let response = request.process(); | ||
/// response.send(client); | ||
/// }) | ||
/// } | ||
/// ``` | ||
/// | ||
/// Now, we can use `?` instead of `match`, and the return type makes a lot more sense: if the loop | ||
/// ever stops, it means that an error occurred. | ||
/// | ||
/// [`String::from_str`]: str/trait.FromStr.html#tymethod.from_str | ||
/// [`Result<String, !>`]: result/enum.Result.html | ||
/// [`Result<T, !>`]: result/enum.Result.html | ||
/// [`Result<!, E>`]: result/enum.Result.html | ||
/// [`Ok`]: result/enum.Result.html#variant.Ok | ||
/// [`String`]: string/struct.String.html | ||
/// [`Err`]: result/enum.Result.html#variant.Err | ||
|
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.
Typo: Infalliable -> Infallible
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.
this still needs fixed