I’ve spent five hours this evening trying to resolve this error:
src/record.rs:61:13: 61:23 error: type mismatch resolving `<R as jmap::record::Record>::Partial == jmap::contact::PartialContact`: expected associated type, found struct `jmap::contact::PartialContact` [E0271]
I found it in the end. Deep in some of my library code I’d inadvertently returned a concrete type instead of a generic type. It just happened to match up with the may I was calling it so it failed oddly.
Finding the problem was made difficult because because I’ve got some fairly deep parameterised types with associated types, across several modules in two crates. Because this was happening in the course of refactoring a lot of code to use associated types and was the first time I’ve used them, I spent a lot of time trying different ways of expressing what I wanted, to no avail. It didn’t help that I wasn’t able to produce an isolated test case, because the problem was actually nothing to do with any of this code - I had it right, the bug was elsewhere.
Through all of this I found myself thinking that this would have been so much easier if the compiler could tell me what it currently knows about the types involved in a portion of code, and in particular why it expects a particular type and where it got that expectation from.
I’m still fairly new to Rust, and so still at the point where I spend a lot of time responding to type errors by moving things around, changing moves to borrows and back and so forth. Its beginner stuff, so I’m not bothered. But it seems to me that if we’re going to have a language where the type system is so integral to everything, then we need tools to very clearly understand what’s going on.
So what is to be done here? Are there tools to inspect rustc’s view of the world during compile? Are there plans? Are there good strategies for working through type errors that I haven’t learned yet? What else? Discuss!