The “learner mode” idea is more appropriate for situations where the error itself makes perfect sense, but the user doesn’t understand how it applies to their specific code, so simply looking up more details on the error message wouldn’t help.
My go-to example is that when you get the “Foo doesn’t implement Trait” error, you might want to ask “why doesn’t this impl block over here cover Foo?” or perhaps “why does calling this function require anything to implement Trait?” or even “why do you think that’s a Foo?” all of which would get totally different answers that wouldn’t make any sense to put in an extended error description for the original error. Though I have no idea how to make that actually work.
Maybe there are some borrow check errors where this sort of thing could help, but it definitely isn’t relevant to this simple example where the explanation is already complete with only three lines of code.
This terminology feels super weird to me, because it sounds like it’s saying Rust actually executed this code and encountered a runtime error when it tried to perform the second borrow.
More generally, I don’t think it makes sense for the compiler to say that it “rejected” code in an error message. The fact that the code was rejected is already obvious because we’re looking at an error message. What we need to say is why it was rejected.
In this case the why is already covered by the main error message at the top, so anything we add to the second inline message is technically redundant (unless we’re expecting users to ignore the top line but carefully read all the other lines?). The only thing I can think of that might be an improvement is trying to make the three inline messages flow together a little better.
| -- immutable borrow occurs here
| ^^^^^^ so cannot borrow mutably here
| - because the immutable borrow is still in use here