A Nullable type for scala3

[johnynek]

I was using explicit nulls recently in a scala3 only project and had to deal with a java API that returned null. I took a moment to make a small wrapper to use a more FP style:

import scala.quoted.*

opaque type Nullable[+T] = T | Null

object Nullable:

  extension [T](inline nullable: Nullable[T])
    transparent inline def fold[A](inline ifNull: => A)(inline fn: T => A): A =
      ${ foldImpl('nullable, 'ifNull, 'fn) }

    inline def isNull: Boolean =
      fold(true)(_ => false)

    inline def nonNull: Boolean =
      fold(false)(_ => true)

    inline def map[B](inline fn: T => B): Nullable[B] =
      fold(null: Null)(fn)

    inline def flatMap[B](inline fn: T => Nullable[B]): Nullable[B] =
      fold(null: Null)(fn)

    inline def toOption: Option[T] =
      fold(None)(Some(_))

    inline def iterator: Iterator[T] =
      fold(Iterator.empty)(Iterator.single(_))

  inline def apply[A](inline a: A | Null): Nullable[A] =
    a

  private def foldImpl[T: Type, A: Type](
      nullable: Expr[Nullable[T]],
      ifNull: Expr[A],
      fn: Expr[T => A]
  )(using Quotes): Expr[A] =
    '{
      val n = $nullable
      given CanEqual[T | Null, Null] = CanEqual.derived
      if (n == null) $ifNull
      else {
        val safe: T = n.asInstanceOf[T]
        ${ Expr.betaReduce('{ $fn(safe) }) }
      }
    }

I think this type could have lawful implementations of many typeclasses: Monad, Traverse, Foldable, Hash, Order, Eq, Monoid, Group (maybe more algebraic typeclasses).

Should I flesh this out and make a PR to add it to cats.data perhaps? It could be nice to have a zero-cost abstraction for nullable types from Java and javascript interop.

[satorg]

Looks pretty neat at first glance – it's like an Option, but more efficient.
I think it's worth a shot.

Does Nullable have to be an opaque type (rather than just a regular type alias for convenience)?
I mean, could all the extension methods as well as Cats typeclasses be imlemented directly on T | Null, thereby avoiding explicit conversion to Nullable?

[johnynek]

I like opaque types because it is clear outside of the file what you are dealing with. If it is on T | Null then we don't own that type and setting up extension methods requires some given import.

That said we do have that already in the code where we add some methods to things. Personally I prefer the opaque type since it is more explicit. What if we provide a Conversion[A | Null, Nullable[A]] or something that people can import?

[johnynek]

Also, if we make it a normal type, then scala rules about methods called on union types wind up coming into play. Here, since it is an opaque type, it is 100% clear where the methods are coming from.

[satorg]

Yes, makes sense, thanks.

What if we provide a Conversion[A | Null, Nullable[A]] or something that people can import?

I'm not sure it's worth the effort. Moreover, Conversion.apply is not inline – so I guess, it won't be inlined.
I think, if we could have something like this:

extension [T](inline nullable: T | Null)
  inline def toNullable: Nullable[T] = ???

then it would be quite enough.

[satorg]

What is the reason for transparent here?

    transparent inline def fold[A](inline ifNull: => A)(inline fn: T => A): A =
      ${ foldImpl('nullable, 'ifNull, 'fn) }

It doesn't seem that the result type needs to be somehow refined based the function input – it is always just A.

[johnynek]

I thought the transparent might allow it to infer union types, since one branch could have one type and the other could have another, but I really don't know.

I'll make a PR.

[joroKr21]

I think this type could have lawful implementations of many typeclasses: Monad, Traverse, Foldable, Hash, Order, Eq, Monoid, Group (maybe more algebraic typeclasses).

I wonder how that works when the type can't be nested 🤔

[johnynek]

PR open: #4823

Indeed @joroKr21 was right: Monad and Applicative aren't lawful, but it seems the rest are.

[johnynek]

@satorg @joroKr21 could you take a look at my PR? I'd love to merge it and move on.

[ritschwumm]

@johnynek is there any story about how to deal with Nullable[Nullable[T]] ? i guess the typesystem can't really know that this is automatically flattened to Nullable[T] at runtime, similar to how typescript has issues to track that a Promise<Promise<T>> is actually always a Promise<T>.

another thing that came to my mind is: what happens if the return type of function passed to map returns a value whose type includes Null? there, a similar "auto-flattening" happens, so e.g. when Nullable[A] is mapped over a function A => B|Null then the result is probably a Nullable[B] and not a Nullable[B|Null]. in my typescript lib, i was too afraid of this to call my method map at all..

[johnynek]

@ritschwumm thr only story to deal with wrapped Nullable is to call .flatten in this PR. The Nullable type is opaque so to the system they are separate types.

That said in Scala 3 you could probably do a deepFlatten which could flatten all the levels. I may try that using a match type.