Standard Library: Now open for improvements and suggestions!

[datalin]

Very happy to hear that the road to additions and improvements is now open!

scala.os Module

While Scala has a solid standard library with a rich collections API, it’s still somehow lacking for some basic tasks. In particular, I think Scala would benefit from having an idiomatic standard module for working with files (along the lines of Python’s pathlib) and performing basic OS operations (akin to Python’s os module).

On one side, this would clearly benefit a majority (or at least a very large portion) of users. On an individual level I know I almost always need to work with files in some way or another. But there’s also data indicating that on Python’s side, the os module is by far the most widely used one.

On another side, while we have a few great external libraries for those operations (with os-lib currently being amongst the top 50 Scala libraries), the use-case is important enough to become standardised.
Also, being part of the standard library would make scripting workflows much more accessible, workflows for which os and path operations are usually central.

Rich Named Tuples API

Named Tuples are great and they attract new use-cases by the day within the community, but their API is currently quite limited. chanterelle already provides some nice additions but I think such an important feature deserves to come packed with useful functionality and common operations. I’m thinking of operations for mapping values, updating / removing fields, etc…

Better Option

Explicit Nulls: Option-like extensions for working with nullable T | Null

Motivation Scala3’s powerful additions enable new (potentially better) ways to think about existing patterns. One such pattern is the handling of potentially missing values, for which the best principled approach has historically been to use the Option monad, which certainly has its merits: Option forces the programmer to consider and deal with the potentially missing case it provides a rich and natural API to do so Nevertheless, with Scala3’s union types and explicit nulls, the union T | Nul…

In the aforementioned post we explored the possibility of empowering nullable types as a better alternative to Option. While the consensus seemed to be that Option would indeed deserve improvements, some valid concerns regarding the widespread use of T | Null were raised.

Regardless of the fate of nullables, I would then like to advocate for better Options ! Here are some preliminary ideas (already suggested in the above thread):

• auto upgrade T values to Option[T] when the latter is expected (i.e. just passing t instead of Some(t) when a value is present), thus reducing the syntax overhead and making the code easier to write and parse
• provide an unboxed runtime representation (when possible), similar to scala-unboxed-option or kyo’s Maybe type.
• consider providing a short alias for Option[T] as T?