Repository navigation
std: Remove generics from Option::expect - #14610
Merged
Merged
Conversation
Member
Author
|
This is my opinion for what should be done, but we don't necessarily have to go down this route. An alternate resolution is to close #14008 and take no further action. |
Contributor
|
👍 from me, (And, anyway, |
Member
|
Why couldn't it live in libcore otherwise? |
Member
Author
|
The "weak failure" system relies on a single point of entry for failure, but by having a generic function the compiler must monomorphize to many entry points of failure, which libcore can't rely on. The other alternative would be for libcore to do the boxing, but libcore doesn't know how to allocate. |
Contributor
|
(Travis failed.) |
This commit removes the <M: Any + Send> type parameter from Option::expect in favor of just taking a hard-coded `&str` argument. This allows this function to move into libcore. Previous code using strings with `expect` will continue to work, but code using this implicitly to transmit task failure will need to unwrap manually with a `match` statement. [breaking-change] Closes rust-lang#14008
bors
added a commit
that referenced
this pull request
Jun 5, 2014
This commit removes the <M: Any + Send> type parameter from Option::expect in favor of just taking a hard-coded `&str` argument. This allows this function to move into libcore. Previous code using strings with `expect` will continue to work, but code using this implicitly to transmit task failure will need to unwrap manually with a `match` statement. [breaking-change] Closes #14008
brendanzab
added a commit
to brendanzab/rfcs
that referenced
this pull request
Jun 19, 2014
This brings the RFC into line with rust-lang/rust#14610
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 5, 2023
…kril fix: Resolve `$crate` in derive paths Paths in derive meta item list may contain any kind of paths, including those that start with `$crate` generated by macros. We need to take hygiene into account when we lower paths in the list. This issue was identified while investigating rust-lang#14607, though this patch doesn't fix the broken trait resolution.
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
May 21, 2025
…4610) A representation attribute `#[repr(…)]` might indicate that the ordering of the fields or the variants is dictated by the API the code is interfacing with. Better not lint with `arbitrary_source_item_ordering` in this case. changelog: [`arbitrary_source_item_ordering`]: do not lint inside items with `#[repr]` attribute
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit removes the <M: Any + Send> type parameter from Option::expect in
favor of just taking a hard-coded
&strargument. This allows this function tomove into libcore.
Previous code using strings with
expectwill continue to work, but code usingthis implicitly to transmit task failure will need to unwrap manually with a
matchstatement.[breaking-change]
Closes #14008