It’s possible to define such an extension method
def[A, B, C] (f: A => B) o (g: B => C): A => C = a => g (f (a) )
but isn’t possible this:
extension on[A, B] (f: A => B) {
def o[C] (g: B => C): A => C = a => g (f (a) )
}
In some cases, it could be useful to be able to define for some higher-order type extension methods with additional type parameters
4 Likes
In some cases, it could be useful to be able to define for some higher-order type extension methods with additional type parameters
Yes, and hopefully that will come at some point. To do this right we need to support multiple type parameter lists on methods, which is non-trivial. Before we get there I’d rather not do something
temporary (like merging parameter lists) since it would likely make it harder to do the right thing later.
For the moment, we have made sure that Tasty supports multiple type parameter lists. So we can upgrade later without changing the format.
4 Likes
Thank you, Martin.
My point is (I’m sure that’s clear for you, I’d like just to unfold some of my considerations), that in “old good” Scala we already can define higher-order extension methods with an implicit class:
implicit class FunOp[A,B](val f:A=>B) extends AnyVal {
def o[C](g:C => A):C => B = c => f(g(c))
// more extension methods ...
}
Now, in Dotty, we got a much more clean syntax for stand-alone extension methods and even, recently, a nice clause ‘extension on’ (and I like it pretty much, thank you!). So it would be a bit disappointing to fall back into “old school” Scala style any times when for some generic type there is needed a bunch of higher-order extensions. Of course, type-classes should help in such cases, but sometimes they are felt like a bit too heavy-weight.
While I understand, that there are some deep consequences on a type theory level, but it would be very nice to have a really simple and clear syntax for higher-order extension methods as well.
Thank you again, Martin!
3 Likes