Add inherent try_from and try_into methods to integer types
#66852
Conversation
|
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Why can't we add the traits to the prelude instead? Do prelude imports still collide with non-prelude glob imports? |
|
This is an idea for “consolation” for not having the @rust-lang/libs what do you think? |
|
@jonas-schievink It looks like this: Building rustdoc for stage2 (x86_64-unknown-linux-gnu)
[…]
error[E0034]: multiple applicable items in scope
--> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/minifier-0.0.33/src/css/token.rs:132:9
|
132 | Operator::try_from(*self).is_ok()
| ^^^^^^^^^^^^^^^^^^ multiple `try_from` found
|
= note: candidate #1 is defined in an impl of the trait `std::convert::TryFrom` for the type `_`
= help: to disambiguate the method call, write `std::convert::TryFrom::try_from(...)` instead
note: candidate #2 is defined in the trait `css::token::MyTryFrom`
--> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/minifier-0.0.33/src/css/token.rs:29:5
|
29 | fn try_from(value: T) -> Result<Self, Self::Error>;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: to disambiguate the method call, write `css::token::MyTryFrom::try_from(...)` instead |
|
Ah, I see. That's unfortunate then... |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
This allows these methods to be used without importing the corresponding traits. This causes new `unused-imports` warnings for existing imports used only by method calls. This is a non-trivial amount of churn, maybe worth it? The warnings can be fixed by removing imports (like this PR does in rustc and tests), or by adding `#[allow(unused_import)]` to them until the minimum supported Rust version is incremented to one that has this PR. The new methods are insta-stable in order to avoid causing `unstable-name-collisions` warnings. These would be harder to deal with since they happen at calls sites rather than trait imports.
SimonSapin
force-pushed
the
inherent-try-from-into
branch
from
628b34f
to
da301ef
Compare
|
I'd rather add these traits to the prelude in the next edition. They're used increasingly more, and PRs like this show that there's definitely a reason to. |
|
Been there, haven’t done that. I proposed this (admittedly only a few months) before the 2018 edition and asked for help with implementing the new lint that would be required by the editions RFC. The Lang team “received [the idea] positively”, and then nothing happened: #51418 (That’s without considering that there aren’t any concrete plans for a future edition so far, and if there’s gonna be one it’s two or three years away at best.) |
|
I'd personally be in favor of a PR like this, seems like a neat strategy to me! |
|
⌛ Trying commit da301ef with merge e922e6444795ab795fab1943288aee3d543699b8... |
dtolnay
added
the
T-libs-api
|
@SimonSapin oh I think @rfcbot fcp merge |
|
Team member @alexcrichton 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. |
rfcbot
added
proposed-final-comment-period
|
☀️ Try build successful - checks-azure |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
I wonder if it's possible to modify the behavior of prelude so that methods from non-prelude traits would have precedence over prelude trait methods, similarly to how non-prelude items have a precedence over prelude items. As in, if there are two traits, and one of those is from prelude, instead of erroring out, it would use non-prelude method instead. This isn't even specifically about this change, it would also allow doing stuff like adding methods from |
|
I think that sounds like a good idea. Would you like to file an issue so it doesn’t get lost in here? |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
Looking at a couple logs, it appears as though the try_from crate no longer works when combined with the |
|
2.4% of regressions is way too much to manage, and I’m afraid most of them are legit. I don’t think it’s particularly tied to I’ve looked at a few and they all appear to be using This seems like it should have been predictable, but that’s always easier to say in retrospect :) I’ll leave it open for a bit in case someone has some other idea or comment, but it looks like we can’t land this PR for pretty much the same reason we couldn’t add these traits to the prelude. |
|
It was worth trying this, but I agree that this is too many regressions to push this through. I think the only downside of not having this is people need to write the As our IDE story improves this is going to get less and less annoying over time. I know in Java land, IDEs tend to be great at filling in practically all imports automatically. |
|
The primary root regressions are as follows. One thought if we do decide to drive this forward is to get the try_from crate to re-export std's types on recent enough versions which would hopefully drastically reduce the amount of breakage here.
|
|
If breakage like this could be acceptable (with changes to some key crates), then probably so is adding the traits to the prelude? Last time around there was some resistance to that idea, though: #49305 (comment) |
|
To be clear, I personally feel similarly to @dtolnay that adding the import is not that hard and we should not cause breakage just for that minor win. I mainly posted the primary root regressions so that folks were aware of the causes of the breakage, if someone wanted to go out and fix crates in the ecosystem. |
|
I don't think this could be done without something like the idea I proposed before in this issue (but I'm still not convinced whether it is really worth it complicating the language, so I didn't make a separate issue for it). |
|
Thanks everyone. It sounds like the two acceptable options are:
Neither involves this PR, so closing. I’m not planning to pursue the language change soon, anyone else who would like to feel free. |
rfcbot
removed
proposed-final-comment-period
This allows these methods to be used without importing the corresponding traits.
This causes new
unused-importswarnings for existing imports used only by method calls. This is a non-trivial amount of churn, maybe worth it?The warnings can be fixed by removing imports (like this PR does in rustc and tests), or by adding
#[allow(unused_import)]to them until the minimum supported Rust version is incremented to one that has this PR.The new methods are insta-stable in order to avoid causing
unstable-name-collisionswarnings. These would be harder to deal with since they happen at calls sites rather than trait imports.