change lower bound of Option.orNull to nullable by olhotak · Pull Request #25733 · scala/scala3

olhotak · 2026-04-08T14:29:25Z

This PR changes the signature of Option.orNull from

  @inline final def orNull[A1 >: A](implicit ev: Null <:< A1): A1 = this getOrElse ev(null)

to

  @inline final def orNull: A | Null = this getOrElse ev(null)

Under -Yexplicit-nulls, type inference sometimes infers A1 to be a non-null type, leading to a failure to find the implicit ev. The new result type is more straightforward for type inference.

Without -Yexplicit-nulls, A | Null is also correct. When A is a nullable type, A | Null is equivalent to A.

How much have you relied on LLM-based tools in this contribution?

No.

How was the solution tested?

Added test option-ornull minimized from akka-management.

Additional notes

This may have to wait until a version when we can start making changes to standard library signatures.

SethTisue · 2026-04-17T23:07:46Z

This may have to wait until a version when we can start making changes to standard library signatures

MiMa says the change is binary compatible. Do you see any source compatibility concerns here?

We're not forbidden from breaking source compatibility, especially under a -Y flag, though we shouldn't do it without thought/consideration, either. Is there any possibility of this breaking user code we should hesitate to break?

SethTisue · 2026-04-17T23:09:16Z

I have taken the liberty of milestoning this for 3.9. My reasoning is that offhand, this looks to me like a pretty basic usability issue for -Yexplicit-nulls, and if we have an opportunity to make -Yexplicit-nulls more usable in an LTS release (that library authors will be stuck on for some years), we should consider taking it.

olhotak · 2026-04-18T01:23:40Z

I don't see any source compatibility concerns here. If any source instantiates A1 with a type that is not a supertype of Null, it would not be able to supply the ev parameter. I don't see a problem, though perhaps somebody else does? @noti0na1 ?

On the contrary, this fixes source compatibility for several of the Open Community Build projects with #25461 (which would turn -Yexplicit-nulls on by default). That PR was the motivation for this PR.

sjrd · 2026-04-18T12:41:44Z

I just realized this is not a backward TASTy compatible change. I thought the Null <:< A1 evidence was enough to guarantee that any valid instantiation of A1 must also be a supertype of Null. But that is not true if that evidence is forwarded from elsewhere, rather than synthesized on the spot. If one has previously written

def foo[A, B >: A](x: Option[A])(using Null <:< B): B =
  x.orNull

the call was previously well typed as x.orNull[B](summon[Null <:< B]). But now, it is not valid anymore because B >: A | Null is not true.

sjrd · 2026-04-18T12:44:47Z

I think an alternative would be to hide this one as protected, and introduce a new one with a simpler signature:

@inline final def orNull: A | Null = this.getOrElse(null)

// binary and TASTy compat
@inline protected final def orNull[A1 >: A](implicit ev: Null <:< A1): A1 = this getOrElse ev(null)

noti0na1 · 2026-04-18T15:41:39Z

I think an alternative would be to hide this one as protected, and introduce a new one with a simpler signature:

Why does adding a protected version not break the compatibility? The new orNull will have a different signature.

sjrd · 2026-04-18T16:09:01Z

Why does adding a protected version not break the compatibility?

Because it's public in bytecode, and TASTy does not check accessibility.

olhotak · 2026-04-18T16:34:47Z

Error:  scala-library-bootstrapped: Failed binary compatibility check against org.scala-lang:scala-library:3.8.0! Found 3 potential problems (filtered 1734)
Error:   * static method orNull(scala.<:<)java.lang.Object in class scala.None does not have a correspondent in current version
Error:     filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("scala.None.orNull")
Error:   * static method orNull()java.lang.Object in class scala.None does not have a correspondent in other version
Error:     filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("scala.None.orNull")
Error:   * method orNull()java.lang.Object in class scala.Option does not have a correspondent in other version
Error:     filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("scala.Option.orNull")

olhotak · 2026-04-25T00:29:31Z

The existing public orNull(ev: <:<) generates a static forwarder in object None. When I change it to final protected, that forwarder goes away, failing binary compatibility (and Mima).

I've changed it to non-final protected and added an extra explicit orNull(ev: <:<) method to object None. Now I think it's binary compatible.

@sjrd could you please confirm that this is OK and review the PR in general?

sjrd · 2026-04-26T10:02:21Z

  def get: Nothing = throw new NoSuchElementException("None.get")
+
+  // for binary and TASTy backwards compatibility 
+  @deprecated @inline override def orNull[A1](implicit ev: Null <:< A1): A1 = null.asInstanceOf[A1]


This is not good. It has at least two issues:

It creates two visible overloads of orNull on None, which are only distinguished by an implicit parameter list.

It turns dispatch on Option.orNull into a bimorphic call, where it was monomorphic before.

I don't think this is an acceptable change.

The static forwarder for None.orNull has approximately 0% chance of being used in the wild. It would have to be called from Java, explicitly passing the evidence of <:<, all to get null. I think we can destroy it.

I went back to the version that adds the backwards-compatibility method only to Option, not to None. I also put in an override for the Mima error on None to get the CI to pass. Is that OK?

sjrd

LGTM from me, other than the misleading placement of the MiMa filter.

I will put it up for discussion at the core meeting tomorrow, to be sure.

SethTisue · 2026-04-29T14:10:41Z

No objections at core meeting today.

(I can imagine that in the future, some similar case might motivate us to build a mechanism to emit a legacy static forwarder when one is needed. But this case doesn't seem nearly important enough to motivate us to build that mechanism now.)

@inline

This PR changes the signature of `Option.orNull` from ```scala @inline final def orNull[A1 >: A](implicit ev: Null <:< A1): A1 = this getOrElse ev(null) ``` to ```scala @inline final def orNull: A | Null = this getOrElse ev(null) ``` Under `-Yexplicit-nulls`, type inference sometimes infers `A1` to be a non-null type, leading to a failure to find the implicit `ev`. The new result type is more straightforward for type inference. Without `-Yexplicit-nulls`, `A | Null` is also correct. When `A` is a nullable type, `A | Null` is equivalent to `A`.

soronpo · 2026-05-09T11:33:04Z

FYI, this causes a regression for ~10 projects in the OpenCB: #26026

olhotak requested a review from a team as a code owner April 8, 2026 14:29

change lower bound of Option.orNull to require nullable type

1cffb20

olhotak force-pushed the option-ornull branch from 7ebe7c1 to 1cffb20 Compare April 8, 2026 16:58

SethTisue added this to the 3.9.0 milestone Apr 17, 2026

olhotak mentioned this pull request Apr 18, 2026

Enable explicit-nulls and unsafeNulls by default #25461

Draft

alternative change to preserve TASTy compatibility

d9290dd

olhotak requested a review from sjrd April 25, 2026 00:29

sjrd requested changes Apr 26, 2026

View reviewed changes

overrule Mima filter for None.orNull

b167d96

olhotak force-pushed the option-ornull branch from 1920d16 to b167d96 Compare April 26, 2026 17:42

olhotak requested a review from sjrd April 26, 2026 20:36

sjrd requested changes Apr 28, 2026

View reviewed changes

Comment thread project/MiMaFilters.scala Outdated

move Mima overrule ProblemFilters line to top of list

7090793

sjrd approved these changes Apr 29, 2026

View reviewed changes

sjrd merged commit a24622b into scala:main Apr 29, 2026
45 checks passed

sjrd deleted the option-ornull branch April 29, 2026 16:51

This was referenced May 9, 2026

[CB] Regression: Option.orNull[T] no longer compiles after #25733 (3.9.0-nightly) soronpo/scala3#9

Closed

Regression: Option.orNull[T] no longer compiles after #25733 (3.9.0-nightly) #26026

Open

soronpo mentioned this pull request May 9, 2026

[CB] Scala 3.9.0 nightly community-build triage — eb2e041 (2026-05-08) soronpo/dottybug#1

Open

92 tasks

Conversation

olhotak commented Apr 8, 2026 • edited by sjrd Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How much have you relied on LLM-based tools in this contribution?

How was the solution tested?

Additional notes

Uh oh!

SethTisue commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SethTisue commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

olhotak commented Apr 18, 2026

Uh oh!

sjrd commented Apr 18, 2026

Uh oh!

sjrd commented Apr 18, 2026

Uh oh!

noti0na1 commented Apr 18, 2026

Uh oh!

sjrd commented Apr 18, 2026

Uh oh!

olhotak commented Apr 18, 2026

Uh oh!

olhotak commented Apr 25, 2026

Uh oh!

sjrd Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

olhotak Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

sjrd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

SethTisue commented Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

soronpo commented May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

olhotak commented Apr 8, 2026 •

edited by sjrd

Loading

SethTisue commented Apr 17, 2026 •

edited

Loading

SethTisue commented Apr 17, 2026 •

edited

Loading

SethTisue commented Apr 29, 2026 •

edited

Loading

soronpo commented May 9, 2026 •

edited

Loading