Code change:
This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.

Related discussion:
text: <ins> //@ check-pass //! Tests that HRTB impl selection covers type parameters not directly related //! to the trait. //! Test for <https://github.com/rust-lang/rust/issues/30867> #![crate_type = "lib"] trait Unary<T> {} impl<T, U, F: Fn(T) -> U> Unary<T> for F {} fn unary<F: for<'a> Unary<&'a T>, T>() {} pub fn test<F: for<'a> Fn(&'a i32) -> &'a i32>() { unary::<F, i32>() } </ins>