Displaying types in errors: absolute path or same as I wrote them?

1

If I use a type such as Vec<Option<_>> the error message about it will print it as std::vec::Vec<std::option::Option<_>>.

Is that a bug or a feature?

Personally, I don’t like how long and syntactically noisy the messages are. I never write Option as std::option::Option, so in this case the message adds a detail that I don’t actually care about.

I suppose there’s a trade-off between being very, very clear about types and using names as written in the code/familar to users.

Would it be desirable to write types in errors in the context of the file they’re in? Taking into account prelude, use/type, etc?

3 Likes
2

I think that’s just a case of “noone got around to implementing it”. This would certainly help make error messages more readable imo.

3

The issue is that while this works for Option, it hardly works for Result. If you get an error that says: Expected Result, but found Result, rather than: Expected std::io::Result, but found std::result::Result, that would be more confusing.

Anyways, it’s a non-trivial problem.

1 Like
4

Heuristic: prepend module names until the two strings are not the same? That would give you Expected io::Result, but found result::Result, which is perfect (IMO). It doesn’t help when you have foo and bar crates that both provide x::y::z::Type, but that is hopefully rare, and it doesn’t do worse then.

5

Good old #21934. I've been wondering if adding a HashMap of local bindings to FnCtxt would be an appropriate solution to this.

The solution to that problem is to keep track of local bindings in every context. You will never have both std::io::Result and std::result::Result available as Result in the same scope. If neither are in scope, the compiler would use the fully qualified path.

3 Likes
6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.