Option.apply should eliminate Nullable type

[Katrix]

minimized code

val maybeNull: String | Null = null
val optionStr: Option[String] = Option(maybeNull)

Returns the error

Found:    (maybeNull : String | Null)
Required: String

expectation

It compiles

[bishabosha]

This is really a request for a new API, we can't change existing API's in the standard library, although perhaps special casing certain nullable API's could work because binary compatibility is preserved

[Katrix]

Doesn't Dotty have the ability to shadow the std library?

[hrhino]

Can we just slap @Nonnull all over the stdlib? I find the annotation ugly but it would help out dotty without breaking any sort of compatibility.

[bishabosha]

@Katrix There is definitely precedent. Dotty does shadow some API's directly in the compiler, such as String.valueOf so that its parameter accepts Any, rather than Object, others can be found in https://github.com/lampepfl/dotty/blob/master/compiler/src/dotty/tools/dotc/core/Definitions.scala

[bishabosha]

scratching the comment I made above, we can define the following (only with -Yexplicit-nulls):

def fromNullable[T](x: T | Null): Option[x.type & T] =
  if x == null then None else Some(x)

which with the OP's example, can be used like

val optionStr: Option[String] = fromNullable(maybeNull)

So, dotc could shadow Option.apply to the same signature

[barnardb]

I just encountered this trying to compile a codebase with -Yexplicit-nulls.

It would be nice to be able to keep the idiomatic null-removing behaviour of Option.apply and have that reflected in the type.

The existing apply method is defined like this:

def apply[A](x: A): Option[A] = if (x == null) None else Some(x)

I think the desired signature change is just to change the argument type from A to A | Null:

def apply[A](x: A | Null): Option[A] = if (x == null) None else Some(x)

The Option[x.type & T] return type in @bishabosha's fromNullable signature above seems nice initially, but it isn't necessary to get rid of the Null from the result type, and unlike with the nn extension method (which has similar x.type & T-style return type), in this method it can cause annoyance by having a self type sneak into the Option in annoying ways. Consider the following code:

trait Resource {
  def subresource(subpath: String): Option[Resource]
}
val resource: Resource = ???
val path: Seq[String] = ???
path.foldLeft(Option(resource))((r, p) => r.flatMap(_.subresource(p)))

One would like this to continue to typecheck as it does now. With a return type of Option[x.type | A] on Option.apply, this wouldn't typecheck, because the type argument for foldLeft will be something like Option[resource.type & Resource] instead of just Option[Resource]. The same applies for a Null-stripping Option-building method, whether it is named apply or fromNullable.

If we need to keep the original apply signature as it is now for backwards compatibility, what about defining an additional method like this:

@targetName("fromNullable")
def apply[A <: AnyRef](x: A | Null): Option[A] = if (x == null) None else Some(x)

Constraining the upper type bound to AnyRef allows the compiler to make an unambiguous choice between the two methods at application sites, and the @targetName annotation sidesteps the same-signature-after-erasure problem. This would allow us to continue the existing idiomatic use of Option.apply to weed out null values, with this now reflected in types as well, and would leave the existing apply method in place for compatibility.

[ckipp01]

It seems the original snippet here no longer errors:

//> using scala 3.3.1-RC1-bin-20230510-d6c643c-NIGHTLY

val maybeNull: String | Null = null
val optionStr: Option[String] = Option(maybeNull)

Am I correct in understanding this is fixed?

[som-snytt]

I think they want a useful Option.apply under -Yexplicit-nulls.