Core Team Meeting Notes

Announcements
4

Core team meeting 19.08.2026

Attendees:

  • Piotr Chabelski as Product Manager

  • Martin Odersky

  • Oliver Bračevac as LAMP Representative

  • Wojciech Mazur as Scala Native Representative, Release Officer and CB Maintainer

  • Tomasz Godzik as Coordinator and VirtusLab Representative

  • Lukas Rytz as Scala 2 Maintainer

  • Seth Tisue as Community Advocate

  • Sébastien Doeraene as Scala.js Representative

Guests:

  • Mikołaj Fornal

Topics:

  1. Java Records pattern matching implementation (with Mikołaj)

    1. https://github.com/scala/scala3/pull/26497#pullrequestreview-4936091864

    2. how should we handle java records varargs in pattern matching?

    3. the case of JavaRecordFields annotation

  2. Releases status

  3. Current status of Metals Worksheets and Mdoc being reliant on the internal compiler APIs.

  4. SLC: Automatic conversion to Option https://contributors.scala-lang.org/t/slc-conversion-a-option-a/7514/37

  5. https://github.com/scala/scala3/pull/26668 Tighten rules for implicit conversions

Conclusions:

  1. In the implementation, the annotation solution seems fine. For pattern matching, yes let’s emit an `unapplySeq` so pattern matches read naturally in Scala (accepting the risk that Java programmers will find this odd/different since, Java unpacks it to Array in pattern matching).

  2. We discussed whether the long series of 3.9 RCs implies we ought to be doing anything differently, e.g. w/r/t the community build. Conclusion: no, we don’t see an opportunity for changes here. We are being especially careful since 3.9 will be LTS.

  3. We will introduce a workaround in Mdoc for Scala 3.10.x, but introduce a concept of worksheets into REPL later on. Multiple tools will be able to interact with it and will give us an opportunity to have a stable API.

  4. Pending an official implementation, but overall it most likely will be accepted provided we also move ahead with 5.

  5. There are two questions here, the timetable of introducing warnings and errors, and the longer-term status of `implicit def` itself. We may need a fresh round of community input in order to find out how many libraries are still dependent on `implicit def` (for real reasons, not just inertia). Seb has proposed considering keeping `implicit def`, if it has turned out that `Conversion` isn’t powerful enough. The warning for Conversion will most likely be merged into 3.10 becoming an error from 3.11.

5 Likes