-
Notifications
You must be signed in to change notification settings - Fork 310
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
Deprecate Itertools::{intersperse, intersperse_with} #576
Deprecate Itertools::{intersperse, intersperse_with} #576
Conversation
I guess they probably need to be removed because the conflict with the standard library version? The following code errors on use itertools::Itertools;
fn main() {
itertools::assert_equal((0..3).intersperse(8), vec![0, 8, 1, 8, 2]);
} The error is:
|
Ideally I'd want to cause as little trouble as possible for users. So I guess in an ideal world, Other ideas:
@jswrenn, you usually have a good grasp about what is best here. Any thoughts? By the way, hope you're fine! |
The easiest for user could be to check the Rust version (e.g. in a build script), and use conditional compilation ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically, I believe what we've done is to remove the offending method upon the stabilization of the stdlib method, sometimes preceeded by a period of deprecation.
Looking at our next milestone, I don't see any breaking changes. So let's mark these functions as deprecated and out a semver-compatible release soon. We'll release 0.11.0 to coincide with the stabilization of Rust 1.57.
(And sorry I've been AWOL! I haven't been fine, but things are steadily getting better. Thank you for all your continued work on this crate.)
Co-authored-by: Jack Wrenn <[email protected]>
... Just version-dependently #[cfg] it out, maybe with a build script? Assuming the Itertools one and the std one are API-compatible? |
The stabilization of |
I agree that the build script/rustc version solution sounds like a good part way solution. Unfortunately it's quite part way since it doesn't fix the problem for those that are pinning an old version of itertools, use a lockfile or use a non-current version like 0.9.*. If rust friends on Zulip and elsewhere decide that cfg(accessible) is the best way, then that would mean the build script/rust version solution is the second best way, though. |
I'm considering closing this PR since there doesn't seem to be any plans of restabilizing |
The reason |
Was this mentioned on zulip or some github discussion? |
I think this comes from rust-lang/rust#88967 (comment), suggesting that if "Extra work" meaning this rust-lang/rust#89151, which also resolves this issue in a much better way - but has no implementation. If deciding in favor of moving something like this PR forward - could a better solution be to check for Footnotes
|
I've been considering our options lately (see further discussion on #702), and wrote out some of the history of the issue in a document: https://hackmd.io/@jswrenn/HyKLk_1Cn I'm going to try to implement RFC2845. If that doesn't work out, Itertools will rename all of its methods to be prefixed with |
@jswrenn was there an update to anything, or just closing out this dead issue? |
Just cleaning house. We're unlikely to deprecate these methods until they've actually been stabilized (and even then, we might just push a new major release that just deletes these methods), and they're unlikely to be stabilized until RFC2845 is implemented. Given the long timeline on this, it's safe to close this PR and revisit things once the situation changes. |
Agreed, thanks for clarifying! |
I think it may be worth to revisit this given that the only reason the Rust feature has not stabilized is because the itertools methods cause a name collision. There's a small movement to explore an alternative name right now, which might avoid the issue if it gets anywhere, but it's worth pointing out that waiting for the official implementation to stabilize before depreciating is essentially putting the cart before the horse: The name conflict is why it has not stabilized. |
is there a reason to rush this? as long as we provide intersperse it seems like a good solution for anyone needing this functionality |
I'm in agreement with @tranzystorekk. A primary goal of itertools is to provide convenience for users, and removing These sorts of conflicts between |
It's definitely the superior solution, but it doesn't look like there's been much interest. |
@jswrenn The trait
Therefore because of the prelude, if the RFC is implemented as is, then one would not shadow the other but we would get a compiler error (resolvable by explicitely qualifying the method). So the rust issue mentions implicit import (prelude) vs explicit import. |
The RFC has some oddities in it and would almost certainly not be implemented as written. It is definitely intended to address this use case. Off the top of my head, I'd recommend a modification that doesn't alter resolution based on how implicit or explicit the import is, but rather solely on the super/sub trait relationship. The exact details should be worked out between the implementor and the lang team. |
These probably need to be deprecated once Rust 1.56.0 has been released (rust-lang/rust#88548)