Tracking issue for `impl Trait` (RFC 1522, RFC 1951, RFC 2071)

[aturon]

NEW TRACKING ISSUE = #63066

Implementation status

The basic feature as specified in RFC 1522 is implemented, however there have been revisions that are still in need of work:

• impl Trait in argument position
  • extend to cover traits
  • support elision Argument-position impl Trait requires a named lifetime #49287
• impl Trait in return position is basically implemented, but:
  • filter lifetimes
  • code accepts types with out-of-scope lifetimes 🚀 existential impl Trait allows lifetimes that would not be allowed by abstract type #46541
  • ICEs when interacting with elision impl Trait Lifetime Elision #43396
  • ICE combining universal and existential ICE combining universal plus existential impl Trait #46685
  • ICE with nested lifetimes Nested "impl trait" with lifetimes causing internal compiler error #46464
  • Infinitely recursive types not detected Infinite size checker doesn't see through impl Trait, leading to rustc overflow #38064
    • Better error message for infinitely recursive types Improve error message for infinitely recursive impl Trait type #47659 (fixed in Forbid recursive impl trait #56074)
  • do not accept nested impl trait described here (fixed in Fix nested impl trait lifetimes #48072)
• let x: impl Trait
• static and const T: impl Trait
• abstract type
  • preliminary refactoring possibility
  • in modules
  • in traits

RFCs

There have been a number of RFCs regarding impl trait, all of which are tracked by this central tracking issue.

• Minimal impl Trait rfcs#1522
  • the original, which covered only impl Trait in return position for inherent functions
• RFC: Finalize syntax and parameter scoping for impl Trait, while expanding it to arguments rfcs#1951
  • settling on a particular syntax design, resolving questions around the some/any proposal and others.
  • resolving questions around which type and lifetime parameters are considered in scope for an impl Trait.
  • adding impl Trait to argument position.
• Named existentials and impl Trait variable declarations rfcs#2071
  • named abstract type in modules and impls
    • Finalize syntax (Permit impl Trait in type aliases rfcs#2515)
    • Update RFC RFC: Associated type bounds of form MyTrait<AssociatedType: Bounds> rfcs#2289 to match that syntax if that RFC gets merged.
  • use of impl trait in let, const, and static positions
• mini-RFC: Finalize syntax of impl Trait and dyn Trait with multiple bounds rfcs#2250
  • Finalizing the syntax of impl Trait and dyn Trait with multiple bounds

Unresolved questions

The implementation has raised a number of interesting questions as well:

• What is the precedence of the impl keyword when parsing types? Discussion: 1
  • e.g., how to associate Send for where F: Fn() -> impl Foo + Send?
  • Resolved by mini-RFC: Finalize syntax of impl Trait and dyn Trait with multiple bounds rfcs#2250.
  • Implemented (?) in syntax: Lower priority of + in impl Trait/dyn Trait #45294
• Should we allow impl Trait after -> in fn types or parentheses sugar? [impl Trait] Should we allow impl Trait after -> in fn types or parentheses sugar? #45994
• Do we have to impose a DAG across all functions to allow for auto-safe leakage, or can we use some kind of deferral. Discussion: 1
  • Present semantics: DAG.
• How should we integrate impl trait into regionck? Discussion: 1, 2
  • Resolved in impl Trait Lifetime Handling #45701
• Should we permit specifying types if some parameters are implicit and some are explicit? e.g., fn foo<T>(x: impl Iterator<Item = T>>)?
  • Current behavior: An error to specify types
  • Other alternatives: treat impl Trait as arguments in the list, permitting migration
• Some concerns about nested impl Trait usage
• Should the syntax in an impl be existential type Foo: Bar or type Foo = impl Bar? (see here for discussion)
  • Settled by Permit impl Trait in type aliases rfcs#2515.
• Should the set of "defining uses" for an existential type in an impl be just items of the impl, or include nested items within the impl functions etc? (see here for example)

[pthariensflame]

@aturon Can we actually put the RFC in the repository? (@mbrubeck commented there that this was a problem.)

[aturon]

Done.

[eddyb]

First attempt at implementation is #35091 (second, if you count my branch from last year).

One problem I ran into is with lifetimes. Type inference likes to put region variables everywhere and without any region-checking changes, those variables don't infer to anything other than local scopes.
However, the concrete type must be exportable, so I restricted it to 'static and explicitly named early-bound lifetime parameters, but it's never any of those if any function is involved - even a string literal doesn't infer to 'static, it's pretty much completely useless.

One thing I thought of, that would have 0 impact on region-checking itself, is to erase lifetimes:

• nothing exposing the concrete type of an impl Trait should care about lifetimes - a quick search for Reveal::All suggests that's already the case in the compiler
• a bound needs to be placed on all concrete types of impl Trait in the return type of a function, that it outlives the call of that function - this means that any lifetime is, by necessity, either 'static or one of the lifetime parameters of the function - even if we can't know which (e.g. "shortest of 'a and 'b")
• we must choose a variance for the implicit lifetime parametrism of impl Trait (i.e. on all lifetime parameters in scope, same as with type parameters): invariance is easiest and gives more control to the callee, while contravariance lets the caller do more and would require checking that every lifetime in the return type is in a contravariant position (same with covariant type parametrism instead of invariant)
• the auto trait leaking mechanism requires that a trait bound may be put on the concrete type, in another function - since we've erased the lifetimes and have no idea what lifetime goes where, every erased lifetime in the concrete type will have to be substituted with a fresh inference variable that is guaranteed to not be shorter than the shortest lifetime out of all actual lifetime parameters; the problem lies in the fact that trait impls can end up requiring stronger lifetime relationships (e.g. X<'a, 'a> or X<'static>), which must be detected and errored on, as they can't be proven for those lifetimes

That last point about auto trait leakage is my only worry, everything else seems straight-forward.
It's not entirely clear at this point how much of region-checking we can reuse as-is. Hopefully all.

cc @rust-lang/lang

[arielb1]

@eddyb

But lifetimes are important with impl Trait - e.g.

fn get_debug_str(s: &str) -> impl fmt::Debug {
    s
}

fn get_debug_string(s: &str) -> impl fmt::Debug {
    s.to_string()
}

fn good(s: &str) -> Box<fmt::Debug+'static> {
    // if this does not compile, that would be quite annoying
    Box::new(get_debug_string())
}

fn bad(s: &str) -> Box<fmt::Debug+'static> {
    // if this *does* compile, we have a problem
    Box::new(get_debug_str())
}

I mentioned that several times in the RFC threads

[arielb1]

trait-object-less version:

fn as_debug(s: &str) -> impl fmt::Debug;

fn example() {
    let mut s = String::new("hello");
    let debug = as_debug(&s);
    s.truncate(0);
    println!("{:?}", debug);
}

This is either UB or not depending on the definition of as_debug.

[eddyb]

@arielb1 Ah, right, I forgot that one of the reasons I did what I did was to only capture lifetime parameters, not anonymous late-bound ones, except it doesn't really work.

[eddyb]

@arielb1 Do we have a strict outlives relation we can put between lifetimes found in the concrete type pre-erasure and late-bound lifetimes in the signature? Otherwise, it might not be a bad idea to just look at lifetime relationships and insta-fail any direct or indirect 'a outlives 'b where 'a is anything other than 'static or a lifetime parameter and 'b appears in the concrete type of an impl Trait.

[nikomatsakis]

Sorry for taking a while to write back here. So I've been thinking
about this problem. My feeling is that we do, ultimately, have to (and
want to) extend regionck with a new kind of constraint -- I'll call it
an \in constraint, because it allows you to say something like '0 \in {'a, 'b, 'c}, meaning that the region used for '0 must be
either 'a, 'b, or 'c. I'm not sure of the best way to integrate
this into solving itself -- certainly if the \in set is a singleton
set, it's just an equate relation (which we don't currently have as a
first-class thing, but which can be composed out of two bounds), but
otherwise it makes things complicated.

This all relates to my desire to make the set of region constraints
more expressive than what we have today. Certainly one could compose a
\in constraint out of OR and == constraints. But of course more
expressive constraints are harder to solve and \in is no different.

Anyway, let me just lay out a bit of my thinking here. Let's work with this
example:

pub fn foo<'a,'b>(x: &'a [u32], y: &'b [u32]) -> impl Iterator<Item=u32> {...}

I think the most accurate desugaring for a impl Trait is probably a
new type:

pub struct FooReturn<'a, 'b> {
    field: XXX // for some suitable type XXX
}

impl<'a,'b> Iterator for FooReturn<'a,'b> {
    type Item = <XXX as Iterator>::Item;
}

Now the impl Iterator<Item=u32> in foo should behave the same as
FooReturn<'a,'b> would behave. It's not a perfect match though. One
difference, for example, is variance, as eddyb brought up -- I am
assuming we will make impl Foo-like types invariant over the type
parameters of foo. The auto trait behavior works out, however.
(Another area where the match might not be ideal is if we ever add the
ability to "pierce" the impl Iterator abstraction, so that code
"inside" the abstraction knows the precise type -- then it would sort
of have an implicit "unwrap" operation taking place.)

In some ways a better match is to consider a kind of synthetic trait:

trait FooReturn<'a,'b> {
    type Type: Iterator<Item=u32>;
}

impl<'a,'b> FooReturn<'a,'b> for () {
    type Type = XXX;
}

Now we could consider the impl Iterator type to be like <() as FooReturn<'a,'b>>::Type. This is also not a perfect match, because we
would ordinarily normalize it away. You might imagine using specialization
to prevent that though:

trait FooReturn<'a,'b> {
    type Type: Iterator<Item=u32>;
}

impl<'a,'b> FooReturn<'a,'b> for () {
    default type Type = XXX; // can't really be specialized, but wev
}

In this case, <() as FooReturn<'a,'b>>::Type would not normalize,
and we have a much closer match. The variance, in particular, behaves
right; if we ever wanted to have some type that are "inside" the
abstraction, they would be the same but they are allowed to
normalize. However, there is a catch: the auto trait stuff doesn't
quite work. (We may want to consider harmonizing things here,
actually.)

Anyway, my point in exploring these potential desugarings is not to
suggest that we implement "impl Trait" as an actual desugaring
(though it might be nice...) but to give an intuition for our job. I
think that the second desugaring -- in terms of projections -- is a
pretty helpful one for guiding us forward.

One place that this projection desugaring is a really useful guide is
the "outlives" relation. If we wanted to check whether <() as FooReturn<'a,'b>>::Type: 'x, RFC 1214 tells us that we can prove this
so long as 'a: 'x and 'b: 'x holds. This is I think how we want
to handle things for impl trait as well.

At trans time, and for auto-traits, we will have to know what XXX
is, of course. The basic idea here, I assume, is to create a type
variable for XXX and check that the actual values which are returned
can all be unified with XXX. That type variable should, in theory,
tell us our answer. But of course the problem is that this type
variable may refer to a lot of regions which are not in scope in the
fn signature -- e.g., the regions of the fn body. (This same problem
does not occur with types; even though, technically, you could put
e.g. a struct declaration in the fn body and it would be unnameable,
that's a kind of artificial restriction -- one could just as well move
the struct outside the fn.)

If you look both at the struct desugaring or the impl, there is an
(implicit in the lexical structure of Rust) restriction that XXX can
only name either 'static or lifetimes like 'a and 'b, which
appear in the function signature. That is the thing we are not
modeling here. I'm not sure the best way to do it -- some type
inference schemes have a more direct representation of scoping, and
I've always wanted to add that to Rust, to help us with closures. But
let's think about smaller deltas first I guess.

This is where the \in constraint comes from. One can imagine adding
a type-check rule that (basically) FR(XXX) \subset {'a, 'b} --
meaning that the "free regions" appearing in XXX can only be 'a and
'b. This would wind up translating to \in requirements for the
various regions that appear in XXX.

Let's look at an actual example:

fn foo<'a,'b>(x: &'a [u32], y: &'b [u32]) -> impl Iterator<Item=u32> {
    if condition { x.iter().cloned() } else { y.iter().cloned() }
}

Here, the type if condition is true would be something like
Cloned<SliceIter<'a, i32>>. But if condition is false, we would
want Cloned<SliceIter<'b, i32>>. Of course in both cases we would
wind up with something like (using numbers for type/region variables):

Cloned<SliceIter<'0, i32>> <: 0
'a: '0 // because the source is x.iter()
Cloned<SliceIter<'1, i32>> <: 0
'b: '1 // because the source is y.iter()

If we then instantiate the variable 0 to Cloned<SliceIter<'2, i32>>,
we have '0: '2 and '1: '2, or a total set of region relations
like:

'a: '0
'0: '2
'b: '1
'1: '2
'2: 'body // the lifetime of the fn body

So what value should we use for '2? We have also the additional
constraint that '2 in {'a, 'b}. With the fn as written, I think we
would have to report an error, since neither 'a nor 'b is a
correct choice. Interestingly, though, if we added the constraint 'a: 'b, then there would be a correct value ('b).

Note that if we just run the normal algorithm, we would wind up with
'2 being 'body. I'm not sure how to handle the \in relations
except for exhaustive search (though I can imagine some special
cases).

OK, that's as far as I've gotten. =)

[nikomatsakis]

On the PR #35091, @arielb1 wrote:

I don't like the "capture all lifetimes in the impl trait" approach and would prefer something more like lifetime elision.

I thought it would make more sense to discuss here. @arielb1, can you elaborate more on what you have in mind? In terms of the analogies I made above, I guess you are fundamentally talking about "pruning" the set of lifetimes that would appear either as parameters on the newtype or in the projection (i.e., <() as FooReturn<'a>>::Type instead of <() as FooReturn<'a,'b>>::Type or something?

I don't think that the lifetime elision rules as they exist would be a good guide in this respect: if we just picked the lifetime of &self to include only, then we wouldn't necessarily be able to include the type parameters from the Self struct, nor type parameters from the method, since they may have WF conditions that require us to name some of the other lifetimes.

Anyway, it'd be great to see some examples that illustrate the rules you have in mind, and perhaps any advantages thereof. :) (Also, I guess we would need some syntax to override the choice.) All other things being equal, if we can avoid having to pick from N lifetimes, I'd prefer that.

[petrochenkov]

I haven't seen interactions of impl Trait with privacy discussed anywhere.
Now fn f() -> impl Trait can return a private type S: Trait similarly to trait objects fn f() -> Box<Trait>. I.e. objects of private types can walk freely outside of their module in anonymized form.
This seems reasonable and desirable - the type itself is an implementation detail, only its interface, available through a public trait Trait is public.
However there's one difference between trait objects and impl Trait. With trait objects alone all trait methods of private types can get internal linkage, they will still be callable through function pointers. With impl Traits trait methods of private types are directly callable from other translation units. The algorithm doing "internalization" of symbols will have to try harder to internalize methods only for types not anonymized with impl Trait, or to be very pessimistic.

[arielb1]

@nikomatsakis

The "explicit" way to write foo would be

fn foo<'a: 'c,'b: 'c,'c>(x: &'a [u32], y: &'b [u32]) -> impl Iterator<Item=u32> + 'c {
    if condition { x.iter().cloned() } else { y.iter().cloned() }
}

Here there is no question about the lifetime bound. Obviously, having to write the lifetime bound each time would be quite repetitive. However, the way we deal with that kind of repetition is generally through lifetime elision. In the case of foo, elision would fail and force the programmer to explicitly specify lifetimes.

I am opposed to adding explicitness-sensitive lifetime elision as @eddyb did only in the specific case of impl Trait and not otherwise.

[nikomatsakis]

@arielb1 hmm, I'm not 100% sure how to think about this proposed syntax in terms of the "desugarings" that I discussed. It allows you to specify what appears to be a lifetime bound, but the thing we are trying to infer is mostly what lifetimes appear in the hidden type. Does this suggest that at most one lifetime could be "hidden" (and that it would have to be specified exactly?)

It seems like it's not always the case that a "single lifetime parameter" suffices:

fn foo<'a, 'b>(x: &'a [u32], y: &'b [u32]) -> impl Iterator<Item=u32> {
    x.iter().chain(y).cloned()
}

In this case, the hidden iterator type refers to both 'a and 'b (although it is variant in both of them; but I guess we could come up with an example that is invariant).