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.