Tracking issue for Result::cloned, Result::cloned_err, Result::copied, Result::c...
source link: https://github.com/rust-lang/rust/issues/63168
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
New issue
Tracking issue for Result::cloned, Result::cloned_err, Result::copied, Result::copied_err #63168
Closed
ksqsf opened this issue on Jul 31, 2019 · 9 comments
Comments
Some unresolved questions for us to resolve while this is unstable:
- Do
*_err
method carry their weight? - Is it right for
cloned
to work onResult<&T, E>
or should it work onResult<&T, &E>
? - Should
cloned
becloned_ok
?
My 2c:
cloned and copied for Result
should do the respective operation to either branch, it seems to me that in most cases where you'd need it fro one you'd need it to handle both branches.
I realize this does make the copied one kinda marginal since most errors are unlikely to be Copy
, but perhaps there is a workaround in the odd case you'd want to copy and yet be able exclude Err
?
I'm in favor of cloned
only cloning the Ok
side, i.e., going from Result<&T, E>
to Result<T, E>
. This API mirrors Option::cloned
, and I think it's more likely that a function of the form fn do_fallible_thing() -> Option<&T>
eventually evolves into fn do_fallible_thing() -> Result<&T, SomeError>
than fn do_fallible_thing() -> Result<&T, &SomeError>
. It's still the possibly-present success value that you want to clone; the fact that the failure path now carries an error (versus just None
) is an incidental detail.
Given that we already have precedent of Result::map
, which applies only to Ok
, and is named map
rather then map_ok
, I feel moderately confident that:
- cloned should only clone
&T
, notE
- it should be named
cloned
, rather thancloned_ok
Not sure about _err
variants, but they are stabilizable separately. So, it seems that we potentially can write a stabilization report here and FCP?
Thanks @matklad for bringing the attention. I believe we generally agree on cloned
and copied
so the _err
variants are left out here.
Stabilization Report
Brief summary
- Add
Result::cloned()
for convertingResult<&T, E>
andResult<&mut T, E>
intoResult<T, E>
by cloning the contents of theOk
part. - Add
Result::copied()
for convertingResult<&T, E>
andResult<&mut T, E>
intoResult<T, E>
by copying the contents of theOk
part.
Test cases
- Doc tests included in the original PR (#63166).
Documentation
- Doc comments included in the original PR(#63166).
Things not covered
- The
_err
variants are not proposed to be stabilized.
Shall we stabilize the cloned
and copied
methods on Result
, per the above stabilization report?
@rfcbot merge
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
Copy link
rfcbot commented 26 days ago
This is now entering its final comment period, as per the review above.
Copy link
rfcbot commented 16 days ago
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No one assigned
None yet
No milestone
Successfully merging a pull request may close this issue.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK