def distinctUtilChanged[T](predicate: (old:T, `new`:T) => Boolean):IterableOnce[T]
Which I have to write some like below for now:
def distinctUtilChanged[T](predicate: (/*old*/ T, /*new*/T) => Boolean):IterableOnce[T]
def distinctUtilChanged[T](predicate: (old:T, `new`:T) => Boolean):IterableOnce[T]
Which I have to write some like below for now:
def distinctUtilChanged[T](predicate: (/*old*/ T, /*new*/T) => Boolean):IterableOnce[T]
This would be a really nice feature, and one of the nicer things about typescript. Quite often I find that I want to use named arguments for things. For example when integrating with a map tile system.
def someUtility(source: (Int, Int, Int) => ImageIO) ....
I’ve used type aliases etc to make it clear that the arguments are x, y and zoom
but it doesn’t feel ideal. I’ve also played with using a SAM type (which is not too bad).
trait TileSource {
fetch(x: Int, y: Int, zoom: Int): ImageIO
}
You’re not the first one who wants anonymous case classes / named tuples (like for example C# and few other languages have). But don’t expect to get then.
In my opinion named tuples should be even the basic building block for structures (and of course parameters lists), and additionally “tagging” them with a name should be the special case. But that’s likely not Scala but a different language…
Given that scala 3 has path dependent function types, this is already possible. See here: Dependent Function Types
How is this supposed to work?
You could write the signature, but you can’t access the “Tuple fields” in the body of the method, of course, as this is type level and not term level.
This does not compile:
trait t:
def distinctUtilChanged[T](predicate: (old: T, `new`: T) => Boolean): IterableOnce[T] =
println(old) // Not found: old
List()
Not sure why that would compile. What you have in scope there is a parameter named predicate
. Now, it is a valid point that predicate(old = ???, new = ???)
won’t work, but that is a different problem.
You’re right! My fault.
Even if this would be a TypeScript object as param for the predicate
function one wouldn’t be able to destructure it directly.
But you would get at least IDE hints for the object fields in TS.
This is unrelated to the point that I think “named tuples” would be nevertheless a really cool addition to Scala.
Oh I’d love native named tuples too. So much code that could benefit from such a thing I think