-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Lower the priority of unstable methods when picking a candidate. #48552
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
I think something along these lines is a good idea, and I especially like how it moves breakage considerations mostly to stabilization PRs where we can better evaluate the relative worth of a given feature compared to the breakage it could cause. |
That's a fantastic idea. If you do this, you can have all the best parts of itertools 😄 and I don't mind. |
Previous iteration rust-lang/rfcs#1321 |
This is a big decision. |
(Note: the CI error is due to (Edit: Bypassed by treating unmarked APIs as stable.) |
Another thing to consider is that people could use the semver trick to hot-swap inherent methods and types with ones from the standard library once they've stabilised. |
c237722
to
941c8b9
Compare
Thanks for the pointer @petrochenkov :) I’ve checked RFC 1321, this PR is slightly different from the RFC that unstable items are still considered (instead of completely hidden) but only with lowest priority. This corresponds to the “weak” alternative in the RFC:
The reason of closing the RFC were that:
|
Thanks for this PR! I don't have time to leave an in-depth comment right now, but yes the major problem with an approach like this is that, in some sense, it defeats the purpose of nightly for testing; we want to know about these conflicts. That said, I agree that doing this via a warning instead gives the best of all worlds. @nikomatsakis said something similar on the original thread, and also pointed out how difficult it may be to get this right. I'll let him comment on the current state of affairs. |
941c8b9
to
4244362
Compare
4244362
to
fa7ca66
Compare
☔ The latest upstream changes (presumably #48615) made this pull request unmergeable. Please resolve the merge conflicts. |
fa7ca66
to
4c39387
Compare
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 27f92ef has been approved by |
@kennytm That explains why it so in the current implementation, but as a compiler user it still seems wrong to me to warn about potential conflicts with traits that would actually not conflict because they are not in scope. |
☔ The latest upstream changes (presumably #49308) made this pull request unmergeable. Please resolve the merge conflicts. |
If there is potential ambiguity after stabilizing those candidates, a warning will be emitted.
…eId`. This clarifies the intent of whether to emit deprecated lint or not.
27f92ef
to
17cc3d7
Compare
@SimonSapin the scope problem only affects suggestions. If the code is real, the out-of-scope traits won't be considered and thus won't have any spurious warnings. The last commit also disabled the warnings if the probe is used for suggestions (the cause of all spurious warnings so far). @bors r=nikomatsakis (Renamed "epoch" to "edition".) |
📌 Commit 17cc3d7 has been approved by |
Lower the priority of unstable methods when picking a candidate. Previously, when searching for the impl of a method, we do not consider the stability of the impl. This leads to lots of insta-inference-regressions due to method ambiguity when a popular name is chosen. This has happened multiple times in Rust's history e.g. * `f64::from_bits` #40470 * `Ord::{min, max}` #42496 * `Ord::clamp` #44095 (eventually got reverted due to these breakages) * `Iterator::flatten` #48115 (recently added) This PR changes the probing order so that unstable items are considered last. If a stable item is found, the unstable items will not be considered (but a future-incompatible warning will still be emitted), thus allowing stable code continue to function without using qualified names. Once the unstable feature is stabilized, the ambiguity error will still be emitted, but the user can also use newly stable std methods, while the current situation is that downstream user is forced to update the code without any immediate benefit. (I hope that we could bring back `Ord::clamp` if this PR is merged.)
☀️ Test successful - status-appveyor, status-travis |
Previously, when searching for the impl of a method, we do not consider the stability of the impl. This leads to lots of insta-inference-regressions due to method ambiguity when a popular name is chosen. This has happened multiple times in Rust's history e.g.
f64::from_bits
Tracking issue for float_bits_conv feature #40470Ord::{min, max}
Add max and min to Ord #42496Ord::clamp
Tracking issue for clamp RFC #44095 (eventually got reverted due to these breakages)Iterator::flatten
Add Iterator::flatten #48115 (recently added)This PR changes the probing order so that unstable items are considered last. If a stable item is found, the unstable items will not be considered (but a future-incompatible warning will still be emitted), thus allowing stable code continue to function without using qualified names.
Once the unstable feature is stabilized, the ambiguity error will still be emitted, but the user can also use newly stable std methods, while the current situation is that downstream user is forced to update the code without any immediate benefit.
(I hope that we could bring back
Ord::clamp
if this PR is merged.)