C-NEWTYPE-HIDE impl Trait is stable

[coryshrmn]

In the future the same thing can be accomplished more concisely with the impl Trait feature but this is currently unstable.

We should update this for Rust 1.26. I think impl Trait is preferred where applicable. Should this guideline be renamed?

[KodrAus]

Hmm, I don't think we should go as far as recommending impl Trait in return position for libraries yet, because they can be quite inconvenient if you need to capture them in structures. Maybe we should remove this paragraph for now while we get more experience with impl Trait to figure out what guidelines to make around it?

[BurntSushi]

Given current Rust stable, the only way I see myself using impl Trait in the return position of a public API is when there is no other choice. For example, when you need to return a type that otherwise cannot be named (like an unboxed closure).

In addition to the issue that @KodrAus mentioned (basically, that impl Trait is not really a first class feature of Rust---at least not yet), the other issue is that you potentially miss out on other conveniences, such as implementations of Clone and Debug. For example, many of the iterator adapters in the standard library implement both Clone and Debug (among other useful traits such as DoubleEndedIterator), which you would lose if you just returned impl Iterator<Item=T>.

It is possible that some of these concerns may be assuaged over time, but that time is definitely not today. We may want to consider adding some part of this discussion to C-NEWTYPE-HIDE instead of completely removing the mention of impl Trait, since it's likely others might have similar thoughts and it would be good to document the trade offs here.

[est31]

I've written up some points on this over at reddit. I arrived at the same conclusion as @BurntSushi : use impl Trait in public interfaces only when there is no other choice.

[est31]

Especially, I think we should wait until we get named existentials (current syntax: abstract type) and then suggest those instead.

[coryshrmn]

I understand, API consumers benefit from named return types. It would be nice for the guideline to mention impl Trait's weaknesses, and recommend API's return impl Trait only for unnameable types.