Scala 3 specific stdlib improvements

Some parts of stdlib could be greatly ehanced by using Scala 3 specific features. One example is ChainingSyntax. Just consider:

  extension [A](self: A):
    inline def tap[U](inline f: A => U): A =
      f(self)
      self
    inline def pipe[B](inline f: A => B): B = f(self)

Using inline here is not only more efficient, it also makes debugging more reliable (no lambdas), exception callstacks shorter and tidier and it e.g. makes return statemens from inside possible, as they are no longer non-local.

I am not sure what are binary compatibility concerns in cases like this and what strategy could be used to implement Scala 3 improvements to some carefully seleected parts of stdlib.

2 Likes

The current strategy is shipping some other code such as in scala.runtime.stdLibPatches.Predef

e.g. assert, implicitly and locally methods are overridden here

Then we intercept any patched definitions when we initialise the compiler and point them to the patched version

Interesting, thanks. I can see assert there, but not locally or implicitly, only summon.

Who and how chooses what will be added there? Is pipe / tap a good candidate?

How many functions can be added before the maintenance burden becomes too heavy? Will Scala 3 improvements in stdlib have to wait until Scala 2.13 dies, which may be practically never?

SIP 51 mentions the issue without solving it.

That document is no longer new, so probably their thinking has evolved since then.

It would be great to get @inline tap under scala 2 and inline under scala 3.

https://docs.scala-lang.org/sips/drop-stdlib-forwards-bin-compat.html

1 Like

Oh that is interesting, I think before 3.0.0 this was the case, but we did some “cleanup” which probably decided it was not worth patching those methods - but at least assert exists in the 2.13 Predef also