Rust compiler do not provide useful information when there are unsatisfied constraints inside CGP component wiring

[soareschen]

Currently, when there is any unsatisfied constraint inside a context-generic provider implementation, it is not shown in the error message when trying to implement a consumer trait. Due to the indirection through blanket implementations, Rust only prints an unhelpful message that the blanket implementation is not implemented without explaining why. More details about this issue is explained in the debugging chapter of CGP book.

There is not much we can do within this project to fix the issue. Instead, this has been reported to the Rust project at rust-lang/rust#134346, with a fix PR available at rust-lang/rust#134348. This serves as a tracking issue for tracking the progress of fixing this at the Rust compiler.

[soareschen]

It seems like the patch from rust-lang/rust#134348 does not cover the case when type equality constraints are not satisfied. I will have to investigate other code paths in Rust's error reporting, and see whether it is possible to report constraint errors caused by type inequalities.

[marvin-hansen]

Thank you for implemening this crate.

I commented on the GH discussion in the book repo before I found this issue; here is the link as reference.

contextgeneric/cgp-patterns#1 (comment)

In a nutshell, I have a use case that very closely resembles the problem CGP solves. I also poked my buddies over at the Iggy project to take a closer look especially w.r.t. to their work on serialization.

For the error issue, I did read through the linked compiler issue and I sense that patching the Rust compiler feels a bit like the hard road thus the suggestion to at least consider the option of generating check traits with a macro.

For the most part, I only need to know which trait bound is not satisfied to find a solution and, from what I saw in the book, the check trait gives me exactly this. In case the default generated check trait doesn't do that trick, I can still remove the derive, implement the check trait manually and uncomment & debug line by line. The recommendation in the book makes perfect sense; althoughogh, in my experience, that might be the case in only 10% to 15% of all issues arising from trait bound violations so having a sensible default for the remaining 80% is certainly more than good enough to get substantial work done.

[soareschen]

@marvin-hansen thanks for your feedback! I have replied you on the other thread. In my experience of using CGP in large scale projects, debugging unsatisfied indirect dependencies are the biggest challenge for using CGP, and the check traits approach is not general enough to handle more advanced cases. I'm still experimenting on better ways to support debugging CGP programs, so hopefully we'll find better approach in the near future.

I'm happy to provide help to solve any challenge you have in the Iggy project. If you can point me to a specific problem, I can help you prototype some changes together and see if it solves the problem. It could also serve as a good blog post for CGP.

[marvin-hansen]

@soareschen

Thank you so much. Just to clarify, I'm not a contributor to the Iggy project myself, it just so happened that because I'm using the Iggy message streaming myself in a relatively large project (> 100 crates) that I came to know the team and their current challenges. I cannot vouch if they are going to use this crate, but they are looking into it.

That said, I'm working on a pluggable integration design pattern with static dispatch using the enum_dispatch crate predominantly for usage in a template service. It's a mind boggling challenge and once the design pattern stands, it will be used to integrate probably up to 50 data sources.

Until I found this crate via TWIR, I had exactly the problem of dispatching multiple default implementations...
Because my V0.1 with proc macros and a lot of trait hackery just worked out last week and nothing has been scaled up yet, I'm okay with rewriting everything using CGP. Another reason is maintainability, flexibility in changing providers later. Basically everything that GCP solves. Error handling really comes second because there is more than one way to solve this, but there are only very few ways to deal with loosely coupling and composing providers and consumers...

I had a chat with some other engineer and the general interest in a no compromise, relatively low code, and full static dispatch zero cost abstraction design pattern for data integration is indeed there.

This may take bit of time, but when it's all set and done, writing a blog post about pluggable integration with CGP is already on my list.

[soareschen]

I have moved the discussion for this topic to https://github.com/orgs/contextgeneric/discussions/3.