Scala 3.5.0 unreachable case which was working with 3.4.2

Karl_s · September 10, 2024, 3:25pm

I’m using Scala 3.5.0 with these compiler options:

    -language:strictEquality
    -Yexplicit-nulls
    -Wsafe-init
    -explain
    -indent
    -new-syntax
    -Xfatal-warnings
    -Wunused:all
    -Wvalue-discard
    -Wnonunit-statement
    -Xcheck-macros
    -source future

The following code gives a (fatal) warning about case _ => being unreachable:

import javax.swing.event.TreeSelectionEvent
import javax.swing.tree.TreePath

class testingCode:
  def process(t: TreeSelectionEvent) =
    val n = t.getNewLeadSelectionPath
    n match
      case tp: TreePath =>
      case _ =>

If I change n match with (n: TreePath | Null) match everything works fine. I’m convinced this wasn’t happening with Scala 3.4.2 (I don’t know about 3.4.3) and in any case if I refer to Explicit Nulls I can’t understand why it complains about an unreachable case. If I open TreeSelectionEvent.java it’s clear that n can be Null.

Unless this is a Scala bug I don’t understand why it’s happening and would love some insight.

WojciechMazur · September 10, 2024, 8:13pm

There was 1 major change related to Explicit Nulls when working with Java libraries, that might not have been documented well.

github.com/scala/scala3

add flexible types to deal with Java-defined signatures under -Yexplicit-nulls

scala:main ← dotty-staging:flexible-types

opened 06:48PM - 30 Jun 23 UTC

olhotak

+541 -158

This is a continuation of #17369. When dealing with reference types from Java…, it's essential to address the implicit nullability of these types. The most accurate way to represent them in Scala is to use nullable types, though working with lots of nullable types directly can be annoying. To streamline interactions with Java libraries, we introduce the concept of flexible types. The flexible type, denoted by `T?`, functions as an abstract type with unique bounds: `T | Null ... T`, ensuring that `T | Null <: T? <: T`. The subtyping rule treats a reference type coming from Java as either nullable or non-nullable depending on the context. This concept draws inspiration from Kotlin's [platform types](https://kotlinlang.org/docs/java-interop.html#null-safety-and-platform-types). By relaxing null checks for such types, Scala aligns its safety guarantees with those of Java. Notably, flexible types are non-denotable, meaning users cannot explicitly write them in the code; only the compiler can construct or infer these types. Consequently, a value with a flexible type can serve as both a nullable and non-nullable value. Additionally, both nullable and non-nullable values can be passed as parameters with flexible types during function calls. Invoking the member functions of a flexible type is allowed, but it can trigger a `NullPointerException` if the value is indeed `null` during runtime. ```scala // Considering class J is from Java class J { // Translates to def f(s: String?): Unit public void f(String s) { } // Translates to def g(): String? public String g() { return ""; } } // Use J in Scala def useJ(j: J) = val x1: String = "" val x2: String | Null = null j.f(x1) // Passing String to String? j.f(x2) // Passing String | Null to String? j.f(null) // Passing Null to String? // Assign String? to String val y1: String = j.g() // Assign String? to String | Null val y2: String | Null = j.g() // Calling member functions on flexible types j.g().trim().length() ```

You can check how it behaves with the -Yno-flexible-types flag.

Karl_s · September 11, 2024, 7:00am

Thank you very much @WojciechMazur, I added the suggested flag and now everything works as it used to with 3.4.2.
I also had to put back a few .nn usages as expected.

I erroneously thought that flexible types are what I wanted, after reading more carefully the Explicit Nulls page I understand that’s not the case.

Thanks again!

noti0na1 · September 11, 2024, 3:41pm

Flexible types give users choices to use a value as nullable or non-nullable.

I think we should produce a better warning here, similar to without explicit nulls:
Unreachable case except for null (if this is intentional, consider writing case null => instead).

In this case, if a value is expected to be nullable, you should give a nullable type annotation to n.

I have created an issue for this: Better warning for matching values with flexible types in explicit nulls · Issue #21577 · scala/scala3 · GitHub