You can force the type parameter of Bar to be a singleton type by using a magic Singleton upper bound:
abstract class Bar[T <: Types & Singleton]
This isn’t ideal though and we’d like to replace it by a more general mechanism (my preference would a precise keyword that can be placed on type parameter and definitions to force type inference to infer the most precise type it finds).
And it failed, since None has type Option[Nothing].
Obviously, reading it doesn’t make sense (the compiler could even tell: None.map will never be executed, because None is immutable, etc.
In real-life examples, some method will return Option[String] somewhere, and potential Nones would be properly inferred to Option[String]. But since this triggered a discussion about Scala’s type inference, maybe it “reveals” a real underlying issue so I thought it could potentially be helpful to post it here.
I guess in theory you could make ???.anyNameAtAll(foo, bar) always compile to just ??? since Nothing is a subtype of everything so in theory has every method that any other type in the world potentially has. But I don’t really see what good could come of that.
Can you open an issue for that? Also I suspect it can be minimized further (the use of a lambda whose expected type comes from a repeated parameter is probably the important part here)