
Announcing Rust 1.30 - steveklabnik
https://blog.rust-lang.org/2018/10/25/Rust-1.30.0.html
======
Boulth
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....](https://github.com/dhall-lang/dhall-
lang/blob/master/README.md#example-configuration)

~~~
oconnor663
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.

~~~
Boulth
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.

~~~
oconnor663
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](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.

~~~
Boulth
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".

------
weberc2
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?

~~~
shepmaster
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/](https://diesel.rs/)

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

    
    
      _async(true)

~~~
weberc2
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.

------
bsaul
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.

~~~
shepmaster
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](https://stackoverflow.com/q/50251487/155423)

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

~~~
gpm
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...

~~~
mark-simulacrum
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.

------
kpcyrd
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.

------
Matthias247
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.

~~~
steveklabnik
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=...](https://play.rust-
lang.org/?version=beta&mode=debug&edition=2015&gist=e73bd3ed13cf9e28e3b0e8e8145be957)

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.

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

