Hacker News new | past | comments | ask | show | jobs | submit login

>> We can’t get rid of it because we have a commitment to not breaking users’ code.

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.






It’s partially that, it’s partially that systems people are very conservative, and it’s partially Rust’s own history before 1.0. People do view major breaking changes very differently these days due to those specific situations, and some people still think Rust changes daily. Systems languages tend to have a stability timeline of “forever.”

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 personally feel like this falls clearly into the soundness hole catagory and should be allowed to be removed in a breaking way. I understand the desire to avoid breaking changes, but soundness issues like this chip away at what "safety" in Rust really means.

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.


Yes, as I said below, this is technically a thing we’re allowed to remove. Maybe someday we will. But we want to be careful.

Editions cannot make this kind of change, as also discussed below.


I think it could be an edition thing though... just say Rust 2019 will not allow `Command::before_exec`. By turning on edition 2019 you've accepted the new brakages that it imposes on you, and this is one of them.

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>::bar@v1.3.2(arg1, arg2)`.


Please see the discussion below; I already discussed this at length :)

Just so I'm clear, are you saying then that it's not possible or desireble to have Rust 201X code link against Rust 201Y STD? Or would that work?

Sorry if I'm not making my thought very clear.


It is not possible to have the standard library be different for different editions; it must be the same in all of them. There’s no #[cfg(edition=“”)] construct.

Can't there be a # [deprecate(untiledition=2018)] to solve this? The standard library contains all the old stuff but it becomes inaccessible in all editions after 2018.

There can not.

Gotcha, thanks for taking the time to explain.

I hope I didn't come off as being to negative about the change. Warnings are still a pretty good solution here.


It’s all good!

Would it be reasonable to introduce a compiler flag that is enabled by default to mark this category of warnings as errors, or would even that need a major version bump?

It’s not really feasible. Maybe in an extreme case, but this just isn’t one. We have done this for fixing language soundness holes, but it is extremely rare. The spirit of the law matters as much, if not more, than the letter.


It’s a policy question, not a technical question. We can absolutely do it technically.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: