On Mon, 2018-01-22 at 16:36 +0100, John Paul Adrian Glaubitz wrote:
On 01/22/2018 04:22 PM, Aleksa Sarai wrote:
I'm not sure we're understanding each other here -- my point was that the *only* Rust project which has this policy for compiling new versions is the Rust compiler. No other Rust project requires this. That's what I meant by "exception, not the rule". So I agree with what you wrote, but it doesn't have much to do with what I was trying to say, which is that the following quote ...
So, you say it's guaranteed that only the Rust compiler will only ever use particular code that will be deprecated in release N+1 or only available in release N-1?
I did build test it myself. I tried building Rust 1.22 with Rust 1.20 which failed with actual compiler errors, not just a warning that I have to use the proper version. And I think it's absolutely not unlikely that Rust project X will run into such a problem as well. What keeps Rust project X from using certain language features that were only recently added or removed?
The problem with Rust is simply the lack of stabilization. It's absolutely insane that they think it's ok to break compatibility in minor versions and it blows my mind that so many people find that acceptable.
Sorry but I think that you have a missunderstanding here (or is me the one that do not get your point) Rust is really stable as a language. But the stability guarantee provided by Rust needs to be understanding as this: * I create a source S, that compile in Rust R and behaves like B Rust guarantee that S, when compiled in R+1, R+2 .. R+n will compile, and the result will behave like B. There is a process of deprecation, and there is a process of optional enablement of new features, and this section can require the removal of some lines in future versions of the compiler, when this change is enabled by default. What you are referring is a different issue: * I create a source S, that compile in Rust R and behaves like B, but I require that my new version S+1 will also compile for the old version of R. That is simply ... uhm ... like no. No one can guarantee this. A new version of your code, if use specific features enabled in one version of Rust, will not compile in a old version of Rust that do not provide this feature at all.
Rust upstream lives in a universe where they think that distributions are an outdated concept. This is why they are shipping their own package manager and consider such breaking changes in minor releases acceptable.
I really do not get your point. Cargo is like make, is not (and will never be) a full feature package manager. Is true that there is an overlap: cargo can download from crates.io, but is not the way to install anything into the system. This is responsibility of the OS. Is only a helper to the developer, during the development process. Cargo is a living code, that is attached to the Rust version. There is a relation between both, so generaly an update of one require the update of the other. What is wrong with that?
What keeps project X from using certain features of Rust? I have seen projects which would only build with Rust Nightly.
That is a decision of the developer. I can agree that some code that depends on Nightly are not good candidates to be package in the OS (like Rocket). But this do not make any 'wrong thing' in the Rust side. Is the developer who decide that the unestable feature that is provided with nightly is OK for the project. Eventually this feature will live in stable (or not), and in any case is responsibility of the developer to change the code to adjust with the new shape of this feature. But once is there, this program (in this exact version) will compile in any future Rust. You have the same problem with C++, but in a different speed. I can use GNU options, or C++17 in my new version of the project, that of course will not copile in gcc 4.6. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org