Since a method-level annotation can be accomplished with a typeclass, but everyone agrees that using typeclasses would be too verbose, perhaps we could make typeclasses more ergonomic? One thing that has always bothered me about typeclasses in Scala is that in the (reasonably common) case where you donât care about the type, you still have to name it:
def foo[T: Typeclass](x: T): Unit = {...only accesses methods via Typeclass[T] ...}
In Rust, you donât have to name the type:
fn foo(x: impl Typeclass) { ... }
This is why the Into pattern works so well:
fn foo(x: impl Into<Int>) { ... }
is more verbose than the proposed x: into Int
, but itâs not a special language construct.
We could do something in similar in Scala, but more powerful. Suppose that in addition to being able to ascribe a type to a parameter, we could also ascribe a type lambda TL
, where the semantics are
def foo(x: TL)
is syntactic sugar for
def foo[T](x: T)(using TL[T])
Then, we could write the very first definition as
def foo(x: Typeclass[_]): Unit = { ... only uses methods on Typeclass ... }
Similarly, for implicit conversions, you could write
def foo(x: Conversion[_, Int]): Unit = { ... }
This is still pretty verbose, but with a succinct alias for Conversion
like Into
, itâs actually less verbose than Rust
def foo(x: Into[_, Int]): Unit
If we want to get really fancy, we could even use an operator like =:>
and infix types to get
def foo(x: _ =:> Int): Unit = { ... }
but thatâs probably too much and I donât even know if it parses.
This is maybe too radical of a proposal, but if you agree with the premise that it would be nice to make typeclasses lightweight enough that they can be used without modification for method-level implicit conversions, then itâs maybe worth thinking through other options.
And yes, Iâm well aware that this will proposal will be very confusing given the recently changed meaning of _
in types. It will have to wait for 3.2 at a minimum, and even then the potential for confusion might be too great. I donât want to focus too much on this specific proposal, just argue that something like it might solve not just the problem at hand, but also make typeclasses easier to use in general.