[masklinn]

edit: please don't downvote finnyspade into the negatives, that's not helpful

> The hint is off, but the actual error is super useful.

I completely disagree. The actual error is very basic and only useful if you already know what it pertains to, that the hint be way off is actively harmful.

> TL;DR Nothing to see here, just a case of "let me google that for you"

No, it's a case of the compiler not helping and just dumping the raw error in your lap, let's not settle for being GCC when we can do better: http://elm-lang.org/blog/compilers-as-assistants

You shouldn't need to google a bloody traits bound error (and may not even be able to, because you're trying Rust on a bus during your commute and have run out of data) (note that the rustc --explain output doesn't quite help either, it also assumes you already understand trait bounds and also suggests implementing the relevant trait on your type, which is the other way around from the issue, a careful read of the code snippets may hint at the solution, but the explanation doesn't point to it)

[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

[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!

[pcwalton]

I don't see how Elm error messages are significantly better than those of rustc in this case. Elm says "expected Foo, found Bar" (with more flowery prose). Rust says "expected Foo, found Bar".

The examples on that page are all extremely simple type errors in the first place, whereas this error message relates to a much more advanced feature (typeclasses/traits). I'd like to see what the ideal trait mismatch error would look like.

I do think that this error could be improved by suggesting #[derive(Debug)], don't get me wrong. But I don't know of any compiler for any language that goes out of its way to explain how to implement an interface on every interface-not-implemented error.

[masklinn]

> I do think that this error could be improved by suggesting #[derive(Debug)], don't get me wrong.

That's what it's already doing:

> src/x/mod.rs:22:33: 22:34 note: `T` cannot be formatted using `:?`; if it is defined in your crate, add `#[derive(Debug)]` or manually implement it

and it's wrong, the error is a missing trait bound not a missing interface implementation

[pcwalton]

Oh, I see. That's just a straight-up compiler bug as far as I'm concerned. Doesn't have much to do with error message philosophy, really. Let's fix it :)