Skip to content
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

Rename Error::provide to Error::provide_context #112531

Closed

Conversation

JonasJebing
Copy link

@JonasJebing JonasJebing commented Jun 11, 2023

Resolves the deref/autoref method name conflict between Error::provide and Provider::provide mentioned in the tracking issue for error_generic_member_access #99301.

Note: provide_context is the method name that was originally proposed in the RFC.

This comment suggests removing the provider API, which would also resolve the name conflict as a side effect. However, even if it is indeed removed, there's still a small chance it'll be brought back later, I guess. Plus, some users (including myself) feel like the name provide_context provides a clearer indication what should be provided.

@rustbot
Copy link
Collaborator

rustbot commented Jun 11, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 11, 2023
@waynr
Copy link
Contributor

waynr commented Jul 19, 2023

@m-ou-se @Amanieu @yaahc please excuse the pings on a PR that's not mine, but does anything need to be done for this PR? It seems like a pretty straightforward rename, though it could impact the rustfmt and rust-analyzer nightly builds which I've seen happen when working on #113464. I'll be working on a PR to thiserror to accompany #113464 but I think it could get hairy trying to maintain two different PRs on this repo AND a thiserror PR so I might just cherry-pick this into #113464.

@JonasJebing
Copy link
Author

@m-ou-se @Amanieu @yaahc please excuse the pings on a PR that's not mine, but does anything need to be done for this PR? It seems like a pretty straightforward rename, though it could impact the rustfmt and rust-analyzer nightly builds which I've seen happen when working on #113464. I'll be working on a PR to thiserror to accompany #113464 but I think it could get hairy trying to maintain two different PRs on this repo AND a thiserror PR so I might just cherry-pick this into #113464.

@waynr for the record, I don't mind you cherry-picking this PR :)

@m-ou-se
Copy link
Member

m-ou-se commented Jul 26, 2023

r? @Amanieu

@rustbot rustbot assigned Amanieu and unassigned m-ou-se Jul 26, 2023
@Amanieu
Copy link
Member

Amanieu commented Aug 4, 2023

Considering the Provider trait is going to be removed, is it still worth renaming this? The removal of Provider solves the original issue.

@waynr
Copy link
Contributor

waynr commented Aug 9, 2023

@Amanieu ah yeah that's a good point. I'm in favor of sticking with provide.

@bors
Copy link
Contributor

bors commented Aug 14, 2023

☔ The latest upstream changes (presumably #113464) made this pull request unmergeable. Please resolve the merge conflicts.

@waynr
Copy link
Contributor

waynr commented Aug 18, 2023

Considering the Provider trait is going to be removed, is it still worth renaming this? The removal of Provider solves the original issue.

Ah shoot, I thought I had responded to this. I agree. Without Provider this is no conflict and no need to prioritize merging this. @JonasJebing any objection?

@JonasJebing
Copy link
Author

Considering the Provider trait is going to be removed, is it still worth renaming this? The removal of Provider solves the original issue.

Ah shoot, I thought I had responded to this. I agree. Without Provider this is no conflict and no need to prioritize merging this. @JonasJebing any objection?

No objection :)

I did mention in this PRs description that the removal of Provider solves the original issue, too.

This comment suggests removing the provider API, which would also resolve the name conflict as a side effect. However, even if it is indeed removed, there's still a small chance it'll be brought back later, I guess. Plus, some users (including myself) feel like the name provide_context provides a clearer indication what should be provided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants