Better Implicit Search Errors: problematic cases wanted!

[tarsa]

Rust-like compiler assistance with implicits

In Principles for Implicits in Scala 3 @odersky wrote:

@odersky

I started the implicit redesign after having asked myself a hard question:

• If implicits are so good why are they not the run-away success they should be? Why do the great majority of people who are exposed to implicits hate them, yet the same people would love Haskell’s type classes, or Rust’s traits, or Swift’s protocols? The usual answer I get from people who are used to current implicits is that we just need minor tweaks and everything will be fine. I don’t believe that anymore.

Since Rust was given as an example of universally acclaimed implementation of typeclasses I think I need to remind how Rust compiler makes typeclasses programmer friendly. It does that through helpful error messages and also that’s what this topic is about.

List of Rust examples I’ve given:

Principles for Implicits in Scala 3

In my opinion, changing keywords from implicit to given/ implied/ whatever is just another minor tweak when it comes to beginner friendliness, albeit bringing heavy migration pain. First I’ll link to my previous post on this subject: Typical problem with implicits is that implicit conversion doesn’t work. Changing syntax for implicits has zero influence on that. A pretty rare and simple to fix problem is when we have to disambiguate between implicit and explicit parameter lists with expli…

Principles for Implicits in Scala 3

I’m talking more about availability of extension methods rather than typeclass instances per se. In Rust, typeclass instance is not available as a value (even trait objects used for having virtual methods are bound to specific struct or enum instances) but instead visibility of a typeclass adds extension methods to a type. Example code in Rust https://www.ideone.com/SXefDQ use struct_here::MyStruct; //use trait_here::MyTrait; // rustc suggest that, IntelliJ inserts automatically mod struct_h…

Principles for Implicits in Scala 3

That’s exactly the case in my Rust example presented here: Principles for Implicits in Scala 3 I provided an example where all definitions are placed in one file which can be misleading. Consider instead a multi-file project with following files: struct_here.rs: pub struct MyStruct; impl MyStruct {} traits/mod.rs: pub mod trait_here; traits/trait_here.rs: use struct_here::MyStruct; pub trait MyTrait { fn print_hello(&self); } impl MyTrait for MyStruct { fn print_hello(&self) {…

Principles for Implicits in Scala 3

For the record, here is a minimized case where Rust compiler gives incorrect suggestion (regarding a typeclass), but that’s still a good starting point https://www.ideone.com/MD2Ah8 trait SuperTrait { type Raw; fn raw(&self) -> Self::Raw; } trait SubTrait: SuperTrait<Raw=i32> {} // compiler suggests changing 'B' to 'B: SuperTrait' // while correct solution is 'B: SubTrait' fn generic_method<A: SubTrait, B>(a: A, b: B) -> A::Raw { a.raw() + b.raw() } fn main() {} Result: er…

In short, given code like subject.extension_provided_though_typeclass(args) Rust compiler:

• scans the whole classpath to search for typeclasses containing the desired method and prints a numbered list of them for the user (up to a few possibilities). Usually the first one is the good one, so maybe some prioritizing by usefullness is done (I don’t remember how, because I’ve not done Rust programming for over a year or so)
• doesn’t seem to look for typeclass instances dependencies as it doesn’t seem to look for typeclass instances at all (only for interfaces) - this probably is because no orphan typeclass instances are allowed in Rust, so all the instances definitions are either next to subject type definition or next to typeclass (i.e. Rust’s trait).
• helps to resolve ambiguities. If extension_provided_though_typeclass is present in multiple imported typeclasses then Rust compiler lists all of them and shows the user how he can disambiguate the call

By allowing compiler to give a list of suggestions, some of them can be false positives but the list as a whole can still be useful. It’s better to try few suggestions that are automatically given than to figure out everything by yourself because compiler couldn’t decide on a single suggestion and because of that it stayed silent.

It seems that compilation error messages in Dotty finally have some of the usefulness that Rust compiler provides.

@julienrf

However, searching for eligible implicit conversions might significantly increase compilation times. (Even though this search would be performed only in case of missing member, so it should not affect the happy path) If the cost of this feature is too important, it could be hidden behind a compilation flag.

Furthermore, it turns out that these implicit conversions take implicit parameters. This means that when the compiler performs the search, it should take implicit parameters into account and check that they are satisfied. In the case they are not satisfied, it should scan the classpath again to find eligible static implicit instances.

Generally the more suggestions the better, provided the message is still readable. However, if that makes compilation much longer then maybe it’s better to make two levels of implicits search depth. For sure there should be an option to disable the whole mechanism for CI/CD builds, which should stay fast (i.e. make it opt out).

Also a general suggestion regarding errors: In Rust errors have codes and that makes them much easier to google, e.g. try googlling “rust E0119”. Rust website also has Rust error codes index - Error codes index and that’s where IDE automatically points to when error code appears in the compilation logs. An added bonus is that the error message for a given error code can be frequently changed and that wouldn’t prevent googling it.