[lang-team-minutes] stabilization and future of impl Trait


FWIW I am starting to like some/any.

Bjarne always says “simple things should be simple”, and this is a good example on how any actually makes things nicer. One should not forget when using it that "there is not a function open", there are infinitely many of them, one for each type that implements AsRef<Path>, this is why one cannot take a function pointer to open, but one can take a function pointer to open::<Type>. Anyhow I am derailing.

@nikomatsakis I think it is clear that there are enough people wanting to explore any Trait as a short-hand syntax. Independently what the outcome of that exploration will be, impl Trait should not close this door. If some Trait leaves it open so that any can be pursued in a backwards compatible way, this might be a better way to proceed with this feature.

Besides this naming issue, are there any other issues in which an hypothetical any Trait RFC could block the impl some Trait RFC ?


AFAIK the “minimal some Trait” RFC allows existentials in function return type position only by design. I can imagine follow up RFCs that incrementally improve some Trait:

  • “some Trait 1.1 in associated type position” (IIRC this already must work for strait methods)
  • “some Trait 1.2 in simple let bindings”: let v: some Iterator = foo();.
  • “some Trait 1.N in pattern type position”: let v : some Iterator = foo(); , let v : Vec<some Iterator> = foo(); struct F { iter: some Iterator, }, fn foo(x : some Iterator);, …

The problem is, I don’t think we have even discussed what we want a complete some Trait feature in Rust to look like (or I missed this discussion, the original RFC kind of got out of hand).

One thing I liked about Macros 2.0, and essential for its quick success, is that there was an RFC about how we would like an ideal but still realistic Macros 2.0 feature to look like, and then follow up RFCs about how do we incrementally get there. Discussing those RFCs is easier if we know where we want to go. [*]

I am missing such a “some Trait 1.0 goals” RFC here. Do we want to be able to use existentials everywhere where we can actually use a type in Rust? I do not know this. It is hard to focus on incrementally getting somewhere if the discussions about where we want to land get mixed in every time we want to make some minimal progress.

I think we should probably need to discuss that first in depth (maybe by bringing the original impl Trait RFC as “impl Trait goals” RFC), and then “minimal impl Trait” would just be “some Trait 0.1”: the first minimal incremental update that lands some value (being able to return unboxed closures and easily return of complex types like Iterators). It seems to me that everybody agrees that the bang for buck of “minimal impl Trait” is something we want independently of where we actually want to land, so I am not suggesting that we should stop this discussion, but rather move the discussion about what the next steps should be to somewhere else where we can discuss the bigger picture.

[*] And unions, and… Another example would be Ticki’s const fn RFC. Instead of closing it, it might have been better to say, “this is too big, too complex, but very detailed: is this where we want to go?” and make it a const fn goals RFC instead. Then once we agree on const fn's goal, we could move to what the core team proposed of, lets start with the minimal incremental updates that give us the biggest bang for buck, like just type-level usize without any kind of predicates, to be able to abstract over arrays, and then improve it from there.

P.S: this might sound like a “process issue”, but I think it is an important one. Maybe its time to improve the “RFC guidelines” for “big language features” to require first an RFC that just gather consensus on “do we want this?”, then another one on “how would we ideally like it to look like?”, and afterwards, minimal concrete steps to get there.


Yes, that is what I meant, and that explains the typeof suggestions in the issue @tomaka linked.

I shouldn’t be surprised that this has already been considered, as impl Trait is being extensively discussed in multiple locations. At least now you’ve given me one more to follow, thanks!


I actually quite like this idea of “Goals RFCs”, though I’m not sure how it will work out in practice – i.e., can you spell out enough to make the path clear, without getting burdened down in details? I guess that e.g. for impl trait, it would let us sidestep a lot of the details around like “what lifetimes get captured” and what not, so maybe yes.


Follow up: I’ve posted an RFC that attempts to answer the questions laid out in this post, and move toward stabilization.


The RFC suggests abandoning any/some, but from this thread I’ve had impression there was a lot of support for them.


The RFC lays out the rationale in detail – please have a look, and leave commentary about points where you disagree!