# RPITITs are not simple opaque types

As stated in the RFC itself, the desugaring of RPITIT in the trait definition only results in associated types, there is no `impl Trait` in the desugared form: https://github.com/tmandry/rfcs/blob/rpitit/text/0000-return-position-impl-trait-in-traits.md#equivalent-desugaring-for-traits.

The desugaring for impls then uses a TAIT as the expected type for the anonymous associated type generated for the RPIT in the trait definition.

Unlike other `impl Trait`, RPITIT does not represent "some type that implements `Trait`", but instead means "each impl will provide some type that implements `Trait`". Unlike other `impl Trait`, RPITIT has the issue that users want to be able to write bounds for RPITIT.

An alternative desugaring for RPITIT would be the following:

trait NewIntoIterator {
    type Item;
    fn into_iter(self) -> impl Iterator<Item = Self::Item>;
}

// becomes
type $<T: NewIntoIterator> = impl Iterator<Item = T::Item>;
trait NewIntoIterator {
    type Item;

    fn into_iter(self) -> $;
}

Now, that desugaring would very rarely be useful, but it does feel *more consistent* to me.