-
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
Warn when a user-defined trait is used on an std library type without full path #50498
Comments
That seems like it will produce a lot of lints on a lot of projects. Maybe it should start out as an allow-by-default clippy lint? |
The That is, users that do any of the above are breaking one of the However, this contract is crate specific, and there are many crates that guarantee that minor semver bumps won't break it - the |
num treats the addition of a method as a breaking change? Really? |
@sfackler IIRC there were a bunch of PRs "ready" waiting for a long time because they added new trait methods (with default impls) that were only merged just before the 0.2. |
+1 to adding this to the compiler and making it warn by default in the new epoch. This particular pattern is a major cause for regressions between Rust compiler versions (see e.g. #43239, #43657, #43665, #41793). If we added the lint to the compiler, we could make it warn-by-default in the 2018 epoch. This would be a breaking change but make make Rust more stable in the long run. |
There are various alternatives to the lint addition:
While PR #48552 was an improvement, it didn't solve the actual issue itself. |
The semver RFC defines these as Schrödinger changes:
which might or might not be major changes depending on how many people complain. For users, these changes can break their code, so they are major changes in practice. Not having a clear policy on this topic, and not having a way to warn users about code that might be breaking the |
Needing to use UFCS for everything sounds miserable -- no autoref, no chains, etc -- so if this happens I think it needs to be coupled with the ability to do something like Also, I think it's a substantial enough idiom change that it should take an RFC. |
One only needs it for trait method calls of non-
First, it is just a warning in this edition, so I don't think we need an RFC for that. Second, for turning this into an error in the next edition we might not need an RFC since we already have a merged one since 1.0 (The semver for the @aturon 's RFC says:
But I cannot find information about this in the Rust reference. How would one write that in the reference at all? The most straight-forward way I can think of is to just state that "if you do this, the behavior is unspecified". Where some Rust toolchains might specify it in such a way that your code compiles and your trait method gets called, and other toolchains specify it in a different way, e.g., such that your code either does not compile, or a different function is called instead, or... that your code compiles, your trait method gets called, but you get a warning about it, which is what I am suggesting here. So from this point-of-view, this is just requesting a warning in this edition to warn about the usage of unspecified behavior. Until it becomes more clear what to do with respect to it here, it is a bit moot to think about what we will do in the next epoch. |
API Guidelines issue on this same topic: rust-lang/api-guidelines#138 |
I'd like rustc to warn me when I use a trait method on a std (or liballoc, core, ...) type without using the full trait path.
That is, if I implement my own trait for a
std
library type:The motivation is that:
std
library adds a new trait with a method calledfoo
and implements it forVec<u32>
my code stops compiling due to an ambiguity errorstd
library adds an inherent method toVec<u32>
calledfoo
that has the same signature asFoo::foo
, my code continues to compile but might silently change behaviorI don't know whether this warning should apply exclusively to the std library or to types defined in external crates as well.
The text was updated successfully, but these errors were encountered: