-
Notifications
You must be signed in to change notification settings - Fork 13.4k
std: Remove generics from Option::expect #14610
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
Conversation
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. |
👍 from me, (And, anyway, |
Why couldn't it live in libcore otherwise? |
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. |
(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
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
This brings the RFC into line with rust-lang/rust#14610
…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.
…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 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 tomove into libcore.
Previous code using strings with
expect
will continue to work, but code usingthis implicitly to transmit task failure will need to unwrap manually with a
match
statement.[breaking-change]
Closes #14008