Totally the correct way to go about it, IMO. Thus my comment about deprecation.
>> There will not be a Rust 2.0.
>> Note that upon using it, you’ll get a warning, so everyone will at least be notified.
:/ That I've mixed feelings about. Why not? Is it because of the fiascos between Perl 5/6 and Python 2/3? Deprecations and warnings about using deprecated features are indeed the correct thing to do, but IMO, aren't the whole picture. I think to all the times I went to compile something, and got to watch a constant stream of warnings for it (or worse, got hit by bugs I shouldn't have because the programmer took time to finally suppress that annoying warning pointing to the flaw in his code). A (very occasional) major version bump to show "These things we found out were actually wrong and said that you shouldn't do N years ago? We meant that, those are gone now," strikes me as the Right Thing for a language with a major focus on correctness, like Rust.
But, since I'm here armchair quarterbacking here on HN, instead of getting my hands dirty building a major language, I'm willing to concede that my opinion might be different were it informed by experience.
Rust does have a strong commitment to safety, but not an absolute commitment to correctness. These things happen very infrequently. Is it really worth taking an extreme action (which a major language version bump is, especially in the systems space) just to turn a few warnings into errors? Currently, we don’t think so. Maybe in 20 years, when (And if! :) ) there is more than one standard library API that suffers this problem, it would be worth it, but at the current time, it just doesn’t seem to make sense.
I think I'd expect to see warnings about the existing safe method being deprecated for a while, then it's complete removal at the time of another edition of Rust. Users of older versions of Rust can still use the removed function, but newer editions ban it.
This could be implemented as a reserved STD function list in the compiler if it must, since as you've mentioned we only have one STD lib atm.
Editions cannot make this kind of change, as also discussed below.
Never mind the fact that the function is still a symbol in the STD library.
I understand if this is too much complier magic, though it seems like the correct idea to me anyway.
Am I missing something?
P.S. symbol version pinning seems like a great idea, I've even dreamt of having exposed syntax for it, e.g. `Foo::<i32>::firstname.lastname@example.org(arg1, arg2)`.
Sorry if I'm not making my thought very clear.
I hope I didn't come off as being to negative about the change. Warnings are still a pretty good solution here.