[fluffything]

I guess that depends on how you code.

Do you ever write code that returns, e.g., an `Iterator` ? e.g.

    fn my_map<T: Mul, I: Iter<Item=T>>(it: I, x: T) -> impl Iterator<Item=T> {
        it.map(|i| i * x)
    }

`impl Trait` in return position is the only way to write that kind of code, because you can't name closures. You can workaround this by re-implementing a custom `Map` iterator... Or if you are dealing with `Future`s, by writing a new custom `Future` type, but with `impl Trait`, you don't need to.

I use it a lot. What before required a lot of boilerplate, now is a one liner.

[Manishearth]

I address this in the second paragraph:

> impl Trait in return position has changed how people code; but that's because it made certain things suddenly possible, which isn't an idiom change as much as obsoleting some old bad workarounds.

this isn't a new idiom. this is code that wasn't possible before suddenly becoming possible, and people using it.