impl PartialEq<{str,String}> for {Path,PathBuf} (and reversed) by Kixunil · Pull Request #105877 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation17 Commits1 Checks0 Files changed
Conversation
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
[ Show hidden characters]({{ revealButtonHref }})
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os PartialEq between strings and paths, both owned and unsized, in both directions.
Because this is trait impl it's expected to be insta-stable.
(rustbot has picked a reviewer for you, use r? to override)
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
Hey! It looks like you've submitted a new PR for the library teams!
If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.
Examples of T-libs-api changes:
- Stabilizing library features
- Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
- Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
- Changing public documentation in ways that create new stability guarantees
- Changing observable runtime behavior of library APIs
Relevant to the library API team, which will review and decide on the PR/issue.
and removed T-libs
Relevant to the library team, which will review and decide on the PR/issue.
labels
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Since this is instantly stable, I think it's worth asking why these weren't implemented before. I doubt this omission was unintentional.
EDIT: Hm, looking at the proposed implementation I think my initial guess as to why was wrong. Still, my question stands,
Ah, looking at the above error it seems like this may cause type inference issues? In which case it would be a breaking change to implement this. See also previous attempts in #31861 and #76189
@ChrisDenton the errors in CI are just changed outputs in UI tests which is fine. I didn't have time to update them and will be unable for a few days I think. The linked issues seem like people gave up too soon but I will look later if different errors appear.
Fair enough. If it's just the case that people keep giving up too early then I don't have any problem. I just prefer to know, if possible, why something seemingly obvious hasn't been done before rather than assuming it's just an oversight.
Comparison of paths and strings is expected to be possible and needed
e.g. in tests. This change adds the impls os PartialEq between strings
and paths, both owned and unsized, in both directions.
@rustbot label -S-waiting-on-review +S-waiting-on-ACP
r? libs-api
Needs FCP for a bunch of PartialEq between str and String with Path and PathBuf. ACP was already accepted.
Though doesn't Deref handle some of them? Hmm...
This needs a crater run because it has the potential to cause type inference failures. Could you please rebase so that I can start the run?
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Labels
This change is insta-stable, so needs a completed FCP to proceed.
Status: This is awaiting some action (such as code changes or more information) from the author.
Relevant to the library API team, which will review and decide on the PR/issue.