Skip to content

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

Merged
merged 1 commit into from
Jun 5, 2014

Conversation

alexcrichton
Copy link
Member

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

@alexcrichton
Copy link
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.

@huonw
Copy link
Member

huonw commented Jun 2, 2014

👍 from me, .expect is just unwrap with the ability to provide a little more information: it shouldn't try to be everything.

(And, anyway, option.unwrap_or_else(|| fail!(some_interesting_value)) isn't too bad.)

@sfackler
Copy link
Member

sfackler commented Jun 3, 2014

Why couldn't it live in libcore otherwise?

@alexcrichton
Copy link
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.

@huonw
Copy link
Member

huonw commented Jun 3, 2014

(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
@bors bors closed this Jun 5, 2014
@bors bors merged commit 896cfcc into rust-lang:master Jun 5, 2014
@alexcrichton alexcrichton deleted the issue-14008 branch June 5, 2014 16:43
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should Option::expect be parameterized over Any + Send?
5 participants