Regression from stable to nightly: nested impl trait is not allowed

[KodrAus]

I have some code that looks a bit like this:

use std::borrow::Borrow;

pub struct Data<TBody>(TBody);

pub fn collect(_: impl IntoIterator<Item = impl Borrow<Data<impl AsRef<[u8]>>>>) {
    unimplemented!()
}

On 1.32.0 (and the current beta 1.33.0-beta.4 2019-01-24 635817b9db20ecdcd036) this compiles successfully.

On the current nightly 1.34.0-nightly 2019-01-28 d8a0dd7ae88023bd09fa this fails with:

error[E0666]: nested `impl Trait` is not allowed
 --> src/main.rs:5:61
  |
5 | pub fn collect(_: impl IntoIterator<Item = impl Borrow<Data<impl AsRef<[u8]>>>>) {
  |                                            -----------------^^^^^^^^^^^^^^^^--
  |                                            |                |
  |                                            |                nested `impl Trait` here
  |                                            outer `impl Trait`

A workaround is just to use generics. Did we mean to change the rules around nested impl trait here?

[jonas-schievink]

Good: rustc 1.33.0-nightly (19f8958 2019-01-23)
Bad: rustc 1.33.0-nightly (01f8e25 2019-01-24)

Commits in that range

[jonas-schievink]

Likely cuplrit: #57730 (this comment seems relevant)

cc @Zoxc

[Centril]

Also nominated for T-Lang's Thursday meeting; from what I can tell, this shouldn't have been allowed in the first place and appears to have been allowed due to a bug in the nested-impl-trait checking logic.

IOW, the snippet above could be interpreted as:

pub fn collect(_: impl IntoIterator<Item = impl for<T: AsRef<[u8]>> Borrow<Data<T>>>) {
    unimplemented!()
}

[nikomatsakis]

I do not know that we have to discuss in the @rust-lang/lang meeting, but I'm not opposed. I agree with @Centril that this should not have been accepted.

In particular, we decided to forbid nested impl trait of this kind:

fn foo() -> impl Foo<impl Bar> { .. }

Basically there are two hidden variables here, let's call them X and Y, and we must prove that:

X: Foo<Y>
Y: Bar

However, the user is only giving us the return type X. It's true that in some cases, we can infer Y from X, because X only implements Foo for one type (and indeed the compiler does inference of this kind), but I do recall that we intended to forbid this -- in part because such inference is fragile, and there is not necessarily a way for the user to be more explicit should the inference fail (so you could get stuck with no way to port your code forward if, for example, more impls are added to an existing type).

The same seems to apply in this situation. Here there are three impl traits, so we have

X: IntoIterator<Item = Y>
Y: Borrow<Data<Z>>
Z: AsRef<[u8]>

Now, based on X, we can determine Y, but knowing Y does not help us to know Z.

So I would argue that this is a bug fix and we should tag the issue as E-needstest (I'd prefer not to issue a warning period unless we know that this affects a broader swath of code).

[KodrAus]

This issue is more subtle than the compiler error message leads us to believe:

nested `impl Trait` is not allowed

$ rustc --explain E0666
error: no extended information for E0666

and is a bit perplexing without the explanation @nikomatsakis gave, given it can be worked around by mechanically replacing impl Trait with generics. It wasn't obvious to me that this was footgun prevention (but to be fair if it had worked as-intended right away it would probably be a bit different).

I'd prefer not to issue a warning period unless we know that this affects a broader swath of code

Hmm, I'm not sure how we could reasonably determine that given the dark matter closed-source floating around? It certainly affected our product code. Is there a reason not to issue a warning period?

[joshtriplett]

Why can we not support "I return something implementing Iterator where the items implement Foo"? That seems useful.