Change method signatures to be explicitly nullable where applicable

[HarrisL2]

This PR changes types throughout the project to be explicitly nullable where applicable. This allows downstream projects to use scala-xml without running into nullability issues if they choose to enable -Yexplicit-nulls in their own project.

However, this PR does not add the -Yexplicit-nulls flag to build.sbt since in compiler version 3.3.x, there were less features for implicit null compatibility with Java symbols, and the project does not compile with the flag enabled. When on version 3.8.0-RC2, the project can be compiled with explicit nulls enabled.

[SethTisue]

This is interesting — it's the first time I've seen a change of this kind suggested outside of the Scala 3 repository itself.

And it's also the first time I've seen the trick used to make it cross-compile on both Scala 2 and Scala 3. 🆒

The main downside I see is on the Scala 2 side, where there is no actual benefit, but the Nullable type will appear in Scaladoc, and might appear in error message and such. I also worry that it might cause other unexpected behavior at compile time, since I don't think any of us are really clear on exactly when and how it might matter when you substitute Nullable[T] for T even when Nullable is just type-level identity.

And for context, note that of course nullability remains rather experimental in Scala 3. If I understand correctly, it can't become non-experimental until Scala 3.10 at the earliest, as 3.9 is already feature-frozen.

And I am reluctant to risk disrupting the very mature, stable, long-proven combination of Scala 2 and scala-xml, where the only gain involves an experimental language feature.

Could we consider the following alternate path?

• scala-xml 2.x remains cross-compiled on Scala 2 and Scala 3.3 LTS
• scala-xml 3.x becomes Scala 3 only and targets Scala 3.10+, eventually moving to the next LTS version after 3.10

We wouldn't need to release a 3.0 version right away; for those adventurous users wanting to experiment with nullable types, we could publish a 3.0.0-Mx series, and only consider going to actual 3.0.0 once nullability is no longer experimental.

For additional context, note that Scala 3.10 will no longer support cross-compilation with Scala 2. That is to say, Scala 3.10 is the version where we enter a Scala-3-only world and we become much freer to revisit legacy codebases with a fresh eye.

[olhotak]

An added complication is that the Scala compiler itself (Scala 3 certainly and probably also Scala 2), in the parser/desugar, generates code that calls into scala-xml. Thus, scala-xml is not just another library, but specifically targeted by the compiler, somewhat like the standard library.

This raises the question of which versions of the Scala compiler will target which versions of scala-xml. In many ways this is like the question of the relationship between versions of the Scala compiler and the standard library. Up until recently, the compiler evolved in the 3.x versions while the standard library stayed at 2.13. That has recently changed with a separate 3.x version of the standard library. It may now be a good time to make a similar change for scala-xml, to decouple a 3.x version of scala-xml from the 2.13 version, as you suggest.

Assuming we go down this path, there are then logistical details to work out. Where will scala-xml 3.x live? Will it be a fork or just a separate build target in the same repository? (From your comments above, it sounds like it must be a fork.)

[SethTisue]

@olhotak I am imagining a branch, not a fork. eventually main would become Scala-3-only, but we would keep a 2.x maintenance branch around

[olhotak]

I'll add that there's a bit of a chicken-and-egg problem. If one enables explicit nulls in a program that contains XML literals, the program stops compiling because those XML literals get desugared into nullable-type-unsafe calls into scala-xml. In order to make nullability non-experimental or at least less-experimental, we should make XML literals work with nullability. A nullability-aware version of scala-xml may not necessarily be the only way to achieve that, but it is currently the preferred way that we are exploring.

[odersky]

An added complication is that the Scala compiler itself (Scala 3 certainly and probably also Scala 2), in the parser/desugar, generates code that calls into scala-xml. Thus, scala-xml is not just another library, but specifically targeted by the compiler, somewhat like the standard library.

I think from 3.10 on we should deprecate and then stop supporting XML syntax in the compiler. That's long overdue. XML should be done with a string interpolator.

[olhotak]

OK. That's reasonable.

That leaves open the question whether the combination of explicit nulls and XML syntax should be made to work during the period when XML syntax is still in the compiler but deprecated. I would lean towards saying that perhaps it's not worth the disruption to scala-xml.

[olhotak]

On the other hand, while that would reduce the urgency, the scala-xml library will presumably live on, so an explicit-nulls Scala 3 version makes sense eventually. However, there's no need for that version to cross-compile to Scala 2.