|
|
|
|
|
|
by jswrenn
1370 days ago
|
|
|
> Also note that you have to go out of your way to get broken by such additions: you have to declare a trait, then implement that trait for a group of types that you didn't define, and then use that trait on standard library types. There's some mild irony here, in that you're replying to burntsushi, who just released 1.0 of a library that employs this pattern: https://news.ycombinator.com/item?id=32762345 I also think you might be downplaying the ease of hitting of the problem, too. While RFC1105 declares that this sort of breakage is acceptable, Rust's maintainers are, in practice, (understandably) hesitant to break builds. The stabilization of `Iterator::intersperse` was aborted after it was discovered that doing so would break the no-less-than 319 crates that directly or transitively depend on `Itertools::intersperse`: https://github.com/rust-lang/rust/pull/89638 Speaking as one of the maintainers of itertools: This whole situation feels kinda awful, and kinda makes me want to discourage others from using itertools. :( |
|
|
oh interesting, the irony lol. Indeed there are many identifiers in there that cause the danger of breakage should the standard library ever add them.
> would break the no-less-than 319 crates
Wow that's a lot. I guess this problem scales with the size of Rust, which is ever increasing in number of users as well as crates. As an anecdote, one of my first additions to the standard library also ran into this, but at a way smaller scale: https://github.com/rust-lang/rust/issues/41793
Back then we didn't have the PR yet that would make nightly functions not conflict with downstream functions: only if you enabled the nightly function the conflict would exist. So it would move that breakage from the introduction to the function to its stabilization.
> and kinda makes me want to discourage others from using itertools. :(
What you get by this pattern is a shared namespace: shared by both itertools and std libraries. In C, every non-file-private function is part of the shared namespace, and there, libraries have evolved to prefix their function names by the name of the library. So if two libraries have a check_for_errors function, there is no conflict as they are named libfoo_check_for_errors and libbar_check_for_errors. So my suggestion would be to change itertools in that pattern. Or you might even use a shortening of the itertools name like itls, as long as nobody would ever add a function name like that to the standard library.