Is the idea that once the migration has been done, we can get rid of that attribute?
I followed the steps here for my (small) projects, and they gave no errors. However, they do give warnings about this attribute when I try cargo +nightly build afterwards.
Okay, so I can get rid of that, right? That line gives warnings on nightly, but errors on beta. Sorry, all this is a bit confusing - I have just started reading the Edition Guide that you mentioned earlier.
Perfect! That’s exactly what I did now - one project had no errors, the other one had quite a few errors with use, but it was a simple text substitution fix, so no worries!
I see that macro namespaces still work differently for macros defined inside the current module vs dependencies.
I hoped that this would change for the final version but seeing this is still the case for the RC I assume this will stay the same?
This is a major usability/teachability issue in my opinion since now you have to learn both the old and the new system and remember that the old system only applies to your current crate.
Are there any plans to fix this in the near future?
But even then, the system would have to stay the same at least until the next edition.
I just wanted to share a data point, that I recently converted rust-belt, a small Piston game, to Rust 2018 using the current beta. This game has over a 100 transitive dependencies, and the experience was great!
Release compile times are normally about 120 seconds, and Rust 2018 was only a few seconds slower (~2%) (with NLL!). I consider this to be a monumental success.
With cargo fix installed by default and ready to go, following the edition guide was a breeze. This was far, far easier than any similar port in any other language I’ve ever used. The fact that Rust 2015 and 2018 crates interop seamlessly is also quite impressive. This is equivalent to depending a C++17 library from C++03, something I’d never even thought to ask for given how wildly inconceivable it would be in C++'s current compilation model.