How to stop these implementation overlaps

[icy gyro]

Wrote a macro to implement a trait on functions, getting issues with implementation overlaps. I believe it's due to the fact that AgentCallback could be interpreted as the context

https://paste.rs/Chkux.rs

Stole the idea from axum https://github.com/tokio-rs/axum/blob/main/axum/src/handler/mod.rs
https://github.com/tokio-rs/axum/blob/c6e6b4ea32f4e052d0f169cc666a6c885e006f13/axum/src/macros.rs#L49

[noble meadow]

post the error

but more directly, couldn’t String be interpreted as the context?

[icy gyro]

Yes it can, fair point. Error is just conflicting implementations of trait ToolMethod<(std::string::String,), std::string::String, _, _, _>

[noble meadow]

well uhm

you know the problem

what’s your desired solution?

[icy gyro]

The ideal solution would be if there were a way to make it work as is. It's all my crate so I can change the trait signature and bounds however I need to so the syntax I'm aiming for will work.

[noble meadow]

What if there is a fn(String) though?

How do you expect the compiler to know whether you want the C = String impl or the String impl?

should the user have to specify by some turbofish?

in fact, those impls aren’t different, why are they even both there?

oh wait, I see they’re a bit different

[icy gyro]

Yeah exactly I didn't think about that until after I wrote it.

[noble meadow]

well, I think you need to decide on what you want then?

e.g. maybe offering two functions for the String and other context case

[icy gyro]

Could wrapping C in a newtype work? Just something like Context<C>

Sort of like Axum's State extractor

[noble meadow]

Yeah, that would work

Another alternative might be defining a trait that C types are required to implement

then if you don’t implement this trait for String, Rust knows that C: YourTrait and String are always disjoint

[icy gyro]

Oh like a marker trait? I think I'd run into orphan rule issues when using the library.

I.E if someone's context were Arc<SomeStruct> it couldn't be implemented right? Since the crate doesn't own Arc or the marker

[noble meadow]

Yeah

so it’s not ideal

i mean you could implement the marker for Arc<impl Marker>

but still

[icy gyro]

Newtype seems the most elegant solution IMO

[noble meadow]

mm

newtypes are always nice

[icy gyro]

Works like a charm, thanks for your help. Now to add the other permutations