Pre SIP: Replace non-sensical @unchecked annotations

Scala Improvement Process
121

when I implemented it I asked about this and the recommendation was to leave everything untouched, (i.e only implement runtimeChecked as a non-default alternative) until comes such a point that we plan to require it over @unchecked

2 Likes
122

As far as I could tell in a quick scan through the SIP and through this discussion, <expr> match ... and val <pattern> = <expr> were discussed, but about what an example like this?

scala> List(Option(1)).forall:
     |   case Some(n) => true
     | 
1 warning found
-- [E029] Pattern Match Exhaustivity Warning: ----------------------------------
2 |  case Some(n) => true
  |  ^
  |  match may not be exhaustive.
  |
  |  It would fail on pattern case: None
  |
  | longer explanation available when compiling with `-explain`
val res2: Boolean = true

Where does one insert @unchecked to silence the exhaustivity warning? (I genuinely don’t know the answer.)

And should this SIP somehow address this case?

123

An obvious workaround is to make the match explicit and add the annotation to it:

List (Option(1)).forall { x =>
  (x : @unchecked) match
    case Some(n) =>
      true
}

(I am not familiar enough with the braceless syntax to write this in it, sorry about that).

124

I think this would be the straightforward braceless way to write it,

  List(Option(1)).forall: x =>
    x.runtimeChecked match
       case Some(n) => true
125

seems two functions now, it was one function before.

126

SIP 57 is shipping since Scala 3.6 as experimental. We plan to standardize it for the next minor release unless someone hits a major problem with it.

5 Likes
127

The two forms for anonymous functions (block of cases or arrow syntax) are equivalent, and translate to functions or partial functions as required.

I wanted to highlight that Scala 3 syntax allows adding the parameter with a minimal diff:

List(42).map:
  case i =>

and without additional indentation:

List(42).map: x =>
  x match
  case i =>

I find the “aligned case” much easier to read when braces are omitted.

Edit: worth noting that Martin mentions somewhere that the reason for accepting

x => x match { case _ => }

as a partial function was specifically to annotate the selector

x => (x: @unchecked) match { case _ => }
1 Like