Autoref specialization doesn’t seem to work with associated types

[KeatonTech]

Hey David,

Sorry if GitHub Issues isn’t the right forum for this, seemed better than reviving an old Reddit thread. I have gotten Autoref specialization to work well in toy cases, but my actual use case has an associated type in it and that causes things to fall down. As a simple (nonsensical) example:

trait MyTrait {
  type MyAssociatedType; 
}

impl<T: Clone> MyTrait for &T {
  type MyAssociatedType = bool;
}

impl MyTrait for String {
  type MyAssociatedType = str;
}

fn<T: MyTrait> get_toy_example(input: T): <T as MyTrait>::MyAssociatedType {
  ...
}

As far as I can tell the issue is simply that Autoref does not apply to the <T as MyTrait> section, so it will not find implementations for anything other than String. If I change it to <&T as MyTrait> then it will find implementations for all Clone structs but will not special-case String.

The experimental specialization feature built into Rust also falls down for associated types (and seems to be gathering dust) so I’m sort of stuck here. You seem to be the foremost expert on Rust specialization so I figured I’d ask :) Am I hosed here?

If so, might be worth updating the case study doc with that second caveat added. It does come up pretty high up on the Google results for Rust specialization.

[dtolnay]

This is the limitation documented in the writeup. https://github.com/dtolnay/case-studies/blob/2d215ae2caca470bf92534b77eb63904a08a9be4/autoref-specialization/README.md#limitations
Since get_toy_example is not a macro, you only get associated item resolution (method resolution, associated type projection) based on the trait bound.

[KeatonTech]

Ah, I see. I am actually writing this for a macro though, but it’s a Derive macro that needs to generate functions outputting the correct type. So I take it the intention isn’t “this only works when you’re writing a macro” but more like “this only works in code that specifically runs as part of a macro, not in the code it generates”?