Announcing Rust 1.18

  fn foo() -> impl Trait {

means "this function returns something that implements the Trait trait, but I'm not gonna tell you what that concrete type is."

This is primarily useful in two cases: first, in an effort for static dispatch, some types can get really long. For example, imagine you wanted to return an iterator of some kind, like this:

    foo.iter().map(|x| x + 1).filter(|x| x % 2 == 0)

the type of this is something like

    Filter<Map<Iter<'_, {integer}>, [closure@<anon>:2:27: 2:36]>, [closure@<anon>:2:45: 2:59]>

which is pretty gross. First of all, you'll notice the type `Filter<Map<Iter`, as you keep adapting the iterator, you get more types. With iterators it's normally not huge, but if you're using Tokio or Diesel, it can get very bad. Here's a type error I ran into recently with Diesel https://pbs.twimg.com/media/C6l_OwSXAAA_Fmo.jpg:large

So, we could write

    fn foo() -> impl Iterator<Item=i32> {

and be done, no matter how many adapters we use. In current Rust, you can do this:

    fn foo() -> Box<Iterator<Item=i32>> {

but now you've introduced a heap allocation and dynamic dispatch; impl Trait has no allocations and statically dispatches.

The second bit is also present in that type, which is this bit

  [closure@<anon>:2:27: 2:36]

Closures have an anonymous type in Rust, and so you cannot write a function that returns a closure without using a Box like above. impl Trait will fix that, by letting you write

    fn foo() -> impl Fn(i32) -> i32 {

or whatever the type of the closure is.

Extends the reach of unboxed statically typed values. It's awesome in its power that way, while still using the same type checked trait model for generics.

For some reason I can't bring myself to consider a specific new attribute to be a "language-level feature", regardless of how much machinery it takes under the hood. To me, that's an API. :P

Which isn't to say that the compiler itself (not counting incremental compilation here) isn't getting faster, but the improvements are gradual rather than the dramatic numbers seen in the OP. We have a website for tracking general compiler perf on a few representative programs: http://perf.rust-lang.org/ . In the benchmarks there it looks like we've shaved off about half a second from the compilation time on most benchmarks since March, though some have improved by multiple seconds and others have remained the same. In the long-term, we're looking at improvements to typechecking (via Chalk: http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowe... ), improvements to linking (via LLD), improvements to debug codegen (via Cretonne: https://internals.rust-lang.org/t/possible-alternative-compi... ), and of course incremental recompilation.

Ah, gotcha.

Yeah, the Standalone NDK is a bit of a pain since the .cargo/config requires absolute paths to the linker/ar. It makes it hard to commit a common config file for multiple people working in one repo.

There seems to be something here: https://github.com/rust-lang/rust-roadmap/issues/17 ?