Scala '22: Proceedings of the Scala Symposium

Regular expressions can easily go wrong. Capturing groups, in particular, require meticulous care to avoid running into off-by-one errors and null pointer exceptions. In this chapter, we propose a new design for Scala's regular expressions which completely eliminates this class of errors. Our design makes extensive use of match types, Scala's new feature for type-level programming, to statically analyze regular expressions during type checking. We show that our approach has a minor impact on compilation times, which makes it suitable for practical use.

Parser combinators provide a parsing experience that balances flexibility and abstraction with writing parsers in a style that remains close to the grammar. Parser combinators can benefit from the design patterns and structure of an object-oriented world, however, and this paper showcases the implementation and implications of various design patterns tailored at parsers in an object-oriented and functional world. In particular, features of Scala, such as implicits and path-dependent types, along with general object-oriented design help make it easy to write and maintain such parsers.

The use of closures, a core language feature of functional programming languages, has become popular in the context of concurrent and distributed programming. Using closures in a concurrent or distributed setting increases safety hazards, however, due to captured variables. Previous work proposed spores, enhanced closures that increase safety by constraining their environment using types. This paper presents Spores3, a completely new library-based implementation of spores for Scala 3. It is shown how the new design is enabled by a unique combination of several new features in Scala 3. Moreover, Spores3 contributes a new, portable approach to serializing closures based on type classes. Its implementation supports the same serialization approach on both the JVM and the JavaScript backends of Scala.

The explicit nulls feature was merged into Scala 3 compiler at the end of 2019, which makes Null no longer a subtype of all reference types. This is the first step to enforce null safety in Scala language. Since then, we are continuously improving the usability to help users migrating to explicit nulls more easily.

The UncheckedNull (originally named JavaNull) was introduced in the original design to allow calling Java members unsafely (Nieto et al. 2020). Due to limited usage and difficulty of implementation, we decided to discard this notion and introduced a new language feature, called UnsafeNulls. By simply importing scala.language-.unsafeNulls, users can create an "unsafe" scope. Inside this scope, Null will have similar semantic as in Scala without explicit nulls, which allows selecting members on nullable variables and assigning nullable values to non-nullable variables without checking. This is useful when a large chunk of Scala code is mainly interacting with nullable values from Java library.

The community projects are used to evaluate this new feature. We found UnsafeNulls can significantly reduce the work of initial migration. This gives users more flexibility to migrate their projects gradually. We also migrated the Scala 3 compiler itself to explicit nulls.