[Manishearth]

Not really going to address the rest of the post but I wanted to point out that `impl Trait` hasn't really changed what's idiomatic. People still use generics in argument position, and while I've seen a couple instances of people using impl Trait in argument position it's not enough to call it an idiom shift.

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.

I'm curious to know why you felt like you had to change your code to be more idiomatic with impl Trait.

----

Nor does it seem like Ok wrapping is the kind of feature that would change what idiomatic Rust is.

[Ar-Curunir]

This is an anecdote, but I'm someone who keeps up rather zealously with language updates, and even though I write a lot of generic-heavy code, I don't think my code contains a single instance of `impl Trait` in either argument or return position, across over 60,000 lines of rust code

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