[finnyspade]

> The actual error is very basic and only useful if you already know what it pertains to

The error is really solid at showing a type mismatch. Which is of the form "I wanted X but you gave me Y".

> that the hint be way off is actively harmful That's true and they could probably do a bit better for type mismatches on type variables vs concrete types

> just dumping the raw error What's the difference between a "raw error" and something else. If the hint was accurate would it still be a "raw error" because it's not styled like those elm errors? Any more info (aside from a better hint which I concede should be better) would have to be an actual explanation of static typechecking which seems a bit extreme.

All I'm saying is while this error isn't a paragon of what all good error messages should be, it's no more cryptic than any other similar error. Even the nicely formatted elm errors say essentially the same thing.

[masklinn]

> The error is really solid at showing a type mismatch. Which is of the form "I wanted X but you gave me Y".

That's not really high praises, "I expected Foo and you gave a Bar" is pretty much level 0 of static type checking which even javac manages, you'd have to work hard to fail to provide even that.

> What's the difference between a "raw error" and something else. If the hint was accurate would it still be a "raw error" because it's not styled like those elm errors?

No, that's the point, if you have extensive hints and decorations it's not just the raw errors anymore.

In fact the Rust compiler/developers (to their credit) try not to provide raw errors, they provides code pointers and hints and macro expansions, the issue is for this error they're all unhelpful to downright incorrect.

> Any more info (aside from a better hint which I concede should be better) would have to be an actual explanation of static typechecking which seems a bit extreme.

That's not true, it could be an explanation of traits and trait bounds, and that does sound helpful to Rust beginners (and not harmful in the least to old hands).

> Even the nicely formatted elm errors say essentially the same thing.

The essentials are the hardly helpful[0] same in every compiler, Elm's error messages are contextual not just in the decoration of the code but in that the text uses more precise terms depending on the error's context, and they provide better explanation and hints.

The compiler doesn't have to whack your fingers with a ruler and yell "WRONG".

[0] they're helpful if you have experience in the cryptic ways of the specific compiler for the specific language, if that's our benchmark G++'s historical error messages are helpful, that doesn't seem to be a majority view

[arielb1]

> That's not really high praises, "I expected Foo and you gave a Bar" is pretty much level 0 of static type checking which even javac manages, you'd have to work hard to fail to provide even that.

If you know the language well, there really isn't anything more to say - your code wants the `Debug` bound, but it is not present. Either change your code or add the bound.

I am going to improve the error reporting to use a better error message in this case.

[masklinn]

> If you know the language well

Right, that's the problematic assumption. The compiler message aren't going to be problematic if the compiler already trained you.

[steveklabnik]

While I don't disagree with your point, I don't agree with your reason. It's not that the compiler has trained you, it's understanding that you must bound generics by a trait to be able to call methods on the resulting value. That's a language-level understanding rather than a reading of tea leaves.

This is also one reason why --explain was added; hopefully the extended diagnostics can help with unfamiliar errors. More experienced users need --explain less.

[masklinn]

> it's understanding that you must bound generics by a trait to be able to call methods on the resulting value. That's a language-level understanding rather than a reading of tea leaves.

Sure but here's the thing: the compiler could know report that, as you note that's language-level understanding, who's to better know the language than the compiler?

> It's not that the compiler has trained you

Maybe saying that you[0] trained yourself (in this case to pattern-match that a type mismatch between a generic T and a trait is pretty certainly a missing bound on T) would be a better way to put it?

The point is, the compiler could[1] be much more precise in its diagnosis, and much more assisting and "mentoring" in its output, but a few people argue that it's unnecessary, because they've built not just a mental model of rust but a library of pattern-matching "low-level" compiler errors into higher-level language errors and can do it in their sleep at this point.

[0] generic, you, me, pcwalton, dons, oleg, basically anyone working with a compiler

[1] I am very much not saying it's easy

[steveklabnik]

I do certainly agree that we can do a lot more. There's always so many things to do...

[bjz_]

It's a reasonably easy error to figure out if you are used to type systems like Rust's, but for those coming from dynamic languages or templated languages like C++ it might take a bit more of a leap to figure it out. It's nowhere near as awful as in C++, but it there is always room to improve!