Discussion: what should we do with DottyPredef before the release?

[anatoliykmetyuk]

This issue is the place to discuss what needs to be done about DottyPredef. DottyPredef is a workaround used to include stuff in the standard Predef. Standard Predef comes from the Scala 2 standard library. Obviously, it would be good to have the contents of the DottyPredef moved inside Predef. But it is not clear how we should proceed with it – now and in the future.

Given the compressed timeframe we have for the Scala 3.0.0 RC1 Release, it would be good to come up with some conclusion on this one by the end of the next week so that we have enough time to act upon the decision.

/cc @nicolasstucki @odersky @sjrd @smarter

[odersky]

See also #10302

[sjrd]

And #10303.

[odersky]

So looking at the early results of these PRs, we seem to be left with the following essential methods

• assert
• valueOf
• summon
• nn

All but nn are simple inline methods. They should be relatively straightforward to add to Predef, or to special case in the compiler. I am not sure what to do about nn yet. Make it an inline method that forwards to a method in scala.runtime, maybe?

[odersky]

Btw the reason to make assert transparent is that we get better code out of it. Here's the translation of
assert(x > 0) with transparent assert:

        if x().>(0).unary_!() then assertFail() else ()

With normal inline assert:

        (if x().>(0).unary_!() then assertFail() else 
          scala.runtime.BoxedUnit$#UNIT
        ):scala.runtime.BoxedUnit

The reason for assertFail is that it's also shorter than throw new AssertionError. But that's maybe not so much of an issue. If we don't want an assertFail in Predef and do want to keep the byte-code concise, we could move it to runtime also.

[sjrd]

Make it an inline method that forwards to a method in scala.runtime, maybe?

Yes, this is exactly what I had in mind.

If we're not too particular about the error message, we could also define it as:

  extension [T](x: T | Null) inline def nn: x.type & T =
    x.getClass() // throws NPE iff x is null; optimized by the JVM
    x.asInstanceOf[x.type & T]

[sjrd]

The reason for assertFail is that it's also shorter than throw new AssertionError. But that's maybe not so much of an issue. If we don't want an assertFail in Predef and do want to keep the byte-code concise, we could move it to runtime also.

It's not that much more concise. For the assert(cond) (without message), it's 10 bytes instead of 7; and for the assert(cond, message), it's 10 bytes instead of 9.

[sjrd]

Btw the reason to make assert transparent is that we get better code out of it. Here's the translation of
assert(x > 0) with transparent assert:

To me that looks more like a limitation of one of the transformation phases, perhaps erasure. Before erasure:

        // transparent:
        if cond.unary_! then throw new AssertionError("assertion failed") else
          ()
        // not transparent:
        (if cond.unary_! then
          throw new AssertionError("assertion failed: hello")
         else ()):Unit

After erasure:

        // transparent:
        if cond().unary_!() then throw new AssertionError("assertion failed")
           else
        ()
        // not transparent:
        (if cond().unary_!() then
          throw new AssertionError("assertion failed: hello")
         else scala.runtime.BoxedUnit$#UNIT):scala.runtime.BoxedUnit

Erasure or an earlier phase could replace Typed(expr, UnitTpe) by expr when it is already in statement position. Or simply by Block(expr, ()).

In any case, that does not seem like a good enough reason to use transparent, by far. We shouldn't use transparent just to get better code. We can improve the compilation pipeline instead.

[sjrd]

Here is a PR to make nn an inline def: #10396