Fn requires to duplicate trait bounds from a trait

help
#1

Hi, I've got two snippets of code:
Rust Playground -- this one works, the idea is like "take an executor only if there are implementations for two requests using this executor". The problem is if there are nested functions each one of them needs a where clause with same bounds and this got worse when there are lots of these requests needed.

With that in mind I've made a trait which covers all needed bounds for an Executor to be suitable: Rust Playground -- suddenly, no luck with this, it still requires bounds that E may execute Request1 and 2, but it is already stated by ExecutorCanBothRequests!

Am I wrong about something here? How can I express my intentions to rustc?

Trait with another type trait bound in where clause - compilation failed
#2

Looks like issue rust-lang/rust#20671. Solutions:

  • Wait for RFC 2089 - Implied bounds to be implemented. This should be already done in Chalk, the new experimental trait solver, but it still needs to become the default one
  • Use trait aliases (from RFC 1733), which are unstable but at least available in the nightly compiler. They're thought for grouping bounds and don't suffer from issue #20671
1 Like
#3

Thank you for a swift response!
Yes, looks like this is it, sadly; anyway, thank you for pointing me to these RFCs

#4

Is there a way to make the nightly compiler use Chalk instead of the default solver?

#5

There's the -Z chalk flag, but the integration is currently extremely unstable. The good news is that op's example compiles, the bad news is that doing more than that is likely to result in some random ICE. A month ago someone opened a couple of issues on ICEs when using -Z chalk and the answer was that it's so experimental that ICEs are to be expected right now.

If you need a solution for this thread's problem then use trait aliases, they're much more stable and usable.

1 Like
#6
Off Topic

My problem is a bit different: I have some complicated type-level programming going on, and I sometimes throw the current trait solver into an infinite loop, where the recursion limit gets hit no matter how high I raise it.

So far, I’ve managed to find alternative formulations that it’ll accept, but they’re less than ideal. I was hoping that Chalk had gotten mature enough to be worth trying.

#7

Related to this topic: