Add parameter name hint to function parameter


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]
5 Likes

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

1 Like

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.

2 Likes

You’re right! My fault. :sweat_smile:

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.

(I was thinking about something like https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAExgZ1pKBVWAbAYQAsBDMAcwFNkAKABwCdqYISpKAuRGgfS4G84eZFzAgAtgCNKDADSIeYSgHdRE6QwC+ASkQBeAHyIAQnCGUy2rgEEGDEgE8APGKkyj-AFCIfiAPR+iBAIGIh0JPbiaFwAChEk4pTsDGhOUA50lHDAYUyorOwGANoADAC6+oj8AHS1jMwFlNUR5BKUYFBomt6+Ab79AHoDiFBE6IgABuGRaBOIpGiIMB0ylBjL5CMZlIBkBD0+fcFgaObVeHDk9HksbJQ0gsJcAIzyPMoMCORcAEw6un22VqJDqIbJbTKIADk-FBj0Qrg0AG4FO9Pmo3AxkZpIft+nj8QTCUSiX0fOMwHAoIgSGg0DByGASJI8JQRnAwvFEslQTl0hDobCRPD1DJkYoVOikYhsdVccT5QrFf5AgB5SQAK0o0EQeBgyRIeEQ4kcoLAeAciDQmQgMGAFoA1hTlEhGHBMgxYGt5GRkFC3h8KDilcGQ-jSSg4Gt4ZTEJQAB7oKnLcGsgVCIUI0UKJSqYUYrFB3wsqmSSr1fK3e7p56vHM-HS4phQEAMJBFF6Ib5lTzdIA )

This is unrelated to the point that I think “named tuples” would be nevertheless a really cool addition to Scala.

1 Like

Oh I’d love native named tuples too. So much code that could benefit from such a thing I think

2 Likes