The module/crate path issues raise a question, why doesn't it mimic what the file system does and have / for absolute paths, and ./ for relative paths? Of course it would probably be to hard to change it now in Rust but the similarity between filesystem paths is uncanny.

Dhall [0] does that, additionally they allow using URL to import code.

[0]: https://github.com/dhall-lang/dhall-lang/blob/master/README....

I think the main drawback of using URLs is that you don't have a uniform way of handling versions and compatibility. It's certainly possible for a server to implement SemVer in it's URL scheme, but I think what you get with a package manager like Cargo is much more consistent.

I was mainly proposing using paths and added URLs as an interesting tidbit but if you check the Dhall Readme I linked there is an example with content integrity (sha256 checksum). As for versioning: use different URL for different version! Even simple /v1 and /v2 would work.

I latched onto the URL idea because it's something we're wondering about with the `peru` project today :) https://github.com/buildinspace/peru/issues/193

Totally, fetching a single version through URLs works now, even on GitHub if you use tags. The tricky part is saying "I'm using 1.0, and 1.1 just came out, so I should upgrade to that." That requires ecosystem-wide agreement that everyone's going to use SemVer, and it assumes that everything's hosted in git or similar where there's a standard way to enumerate the available versions.

Well tags are usually perceived as immutable but one can imagine adding an info to the tag with the "next version" coordinates.

For example, tag v1.0: and a text at the bottom of the message "Next-Version: v1.1".

Or if one can enumerate versions/tags you could add back pointers to new versions/tags. Example, tag v1.1 with message including "Replaces-Version: v1.0".

I'm not a Rust user, but I'm always keeping an eye on it as it drives for improved usability and intuitability. I really admire the open-mindedness and devotion toward improvement that the Rust community displays.

One question I have about this update in particular: The raw identifiers syntax addition seems like syntax support for a convention. For example, I could use `r#for` or `_for` to solve the same problem, however, the first requires special syntax and the second doesn't. What does the syntax facilitate that a leading underscore doesn't?

The future use for this will be to allow calling methods/functions/macros from 2015 edition code in 2018, where some additional keywords have been reserved.

For example if you are using a crate with "dyn" as a method name then from 2015 you can call it via some_crate::dyn() but in 2018 you couldn't, since it's a keyword, but you could use some_crate::r#dyn(). That's the primary intent for this addition, though I believe some other use cases might be available as well.

In edition 2018, Rust now has reserved `async` and `await` as keywords. Since crates written targeting edition 2018 need to interoperate with edition 2015 (and vice-versa), some syntax is needed to be able to use identifiers that are also keywords.

For example, my 2015 crate might have a function `fn async(enabled: bool)` that I need to call from 2015. I could call it as `r#async(true)`.

This follows the existing syntax of `r"foo"` / `r###"foo"###` for raw strings as well as raw byte literals: `br##"HELO"##`;

Another use case will be for libraries like Diesel [0], a SQL query builder. People want to be able to search the documentation for SQL's `WHERE`, but `where` is keyword in Rust. They could choose to add a method called `r#where` to allow this kind of discoverability.

[0]: https://diesel.rs/

I read the parent as suggesting that you could call it as

  _async(true)

No, this isn't what I meant to imply (though I understand your confusion). I didn't realize (or understand) that the syntax is meant to facilitate interoperability between different versions of Rust.

Ah. If that's the case, as you point out people might have already been using a leading underscore (although they shouldn't for idiomatic reasons), leading to ambiguity around

2015 code:

     fn async(enabled: bool) {}
     fn _async(enabled: bool) {}

2018 code calling that:

    _async(true); // Which is this calling?

r#for is really "for". The reason is backwards compatibility. Rust 2018 may have new keywords which can be used for symbol names in 2015 crates. So to be able to reference such symbols from a 2015 crate in a 2018 crate you need this new syntax.

Well, making a leading underscore special would also be "syntax support", just in a different form.

This particular idea was not brought up during the RFC process, though several alternative syntaxes were. Leading underscore is already a thing in Rust, see shepmaster's posts on why this is not enough.

FWIW, we pretty much just followed existing languages here.

Just out of curiosity : what are the next big features related to the borrow / ownership management ? I've always heard that was rust main pain point, so i'm wondering what are the Rust devs main long-term improvements on that matter.

Non-lexical lifetimes [0] are scheduled to be enabled in the Rust 2018 edition, which will be the default edition as of Rust 1.31, the next release.

After that, there's still some work that can be done towards NLL, specifically some details around how borrowing across functions works when the compiler "should" know that there actually isn't a borrow. This is part of some work codenamed "Polonius" [1], which should also improve the compiler time required to apply the borrow checker's rules.

[0]: https://stackoverflow.com/q/50251487/155423

[1]: https://github.com/rust-lang-nursery/polonius

I think Polonius is such a great name for that project. For those who didn't read Shakespeare's Hamlet, Polonius is known for giving the advice "Neither a borrower nor a lender be."

Is NLL going to be tied to Rust 2018 now? As someone who has been programming with #![feature(nll)] for a long time that would be unfortunate...

For the initial release, NLL will be enabled in "migration" mode in 2018 only. `#![feature(nll)]` will continue to be available -- that hard-enables MIR borrowck instead of the migration mode. (edit: to be clear, the feature gate is not stabilized, but it will be available on nightly)

Migration mode means that the MIR borrow check will run, and if it errors, then AST borrow check will run, and if that compiles successfully then the MIR borrow check errors will be downgraded to warnings. If MIR borrow check is successful then AST borrow check does not run and its errors will not impact the results.

Eventually we will enable MIR borrowck fully on all editions; I personally hope this happens sooner rather than later so we can delete the old code, but we have no concrete timeline just yet.

While there are a lot of really nice things in this release, the progress bar is what got me the most excited. Given the long compile time of some of my projects this is much appreciated.

Are raw identifiers "compatible" with normal ones? E.g. if i define fn r#something(), can I call it just as something()?

Besides the backward compatibility reason they might also be good for codegen tools. I encountered the situation multiple times that some identifier was used in an IDL (e.g. Thrift, Protobuf, etc) that then got exported into a keyword in a target language which prevented it from compiling. To word around that sometimes the IDL definition needed to be changed, which wasn't ideal. By generating only raw identifiers this can be avoided.

The only reason to define it as `r#something` is if something is a keyword, and so regular-old `something` doesn't work. But if you happened to do it anyway, then yeah: https://play.rust-lang.org/?version=beta&mode=debug&edition=...

But yes, the `r#` isn't part of the name; if I define a Rust 2015 function as `fn async()`, in 2015 i can call it as just regular async() in 2015 code, and only need r#async() in Rust 2018 code.

And yeah, this is useful for codegen tools as well.

Thanks to the Rust team! Rust 2018 release is one step closer.