Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Scala with Explicit Nulls #5747
This PR sketches how to change the Scala type system so that reference types are no longer implicitly nullable. Instead, nullability can be recovered via union types (e.g. nullable strings have type
See the accompanying doc for a description of the design: https://gist.github.com/abeln/9f79774bac111d99b3ae2cb9016a33e6
The changes include
Unfortunately, the changes end up touching many components within the compiler (parser, typer, implicits, etc.), since assumptions about Null are baked in in many places. However, the code that
There are still a few (very) important TODOs:
However, before embarking on 2. and 3. we wanted to get feedback from the Dotty team and the community on how things are looking.
Any and all feedback is greatly appreciated!
dotty-bot left a comment
Hello, and thank you for opening this PR!
All contributors have signed the CLA, thank you!
We want to keep history, but for that to actually be useful we have
Please stick to these guidelines for commit messages:
Have an awesome day!
Very cool! Before we get to reviewing this PR, it'd be helpful if it was cleaned up a bit, there's many commits like "fix tests" which are not really meaningful on their own. Ideally, commits in a PR should be atomic: serve a clear purpose detailed in their commit message, and pass all tests (we don't actually enforce that in the dotty repo currently). This PR also needs to be rebased.
Would it be possible to gate the invasive semantic changes of this PR behind a compiler flag ? This way we could merge it even if we're not sure if we'll accept it, and it'll allow more experimentation in the wild.
https://gist.github.com/abeln/9f79774bac111d99b3ae2cb9016a33e6 states that
It looks like the behavior of this proposal is being discussed at https://contributors.scala-lang.org/t/wip-scala-with-explicit-nulls/2761 which is just as well since it means we can limit the comments on this PR to discussing the implementation.
@smarter I think we should be able to gate the changes behind a flag.
I don't know how to make the changes atomic, since the algorithm for developing the feature so far has been
Some test fixes involve changing just the tests, but others modify the compiler.
The one way to have a less atomic change, but one that keeps the tests passing, would be to squash all the commits into a one.
For reviewing the PR, I think the best way is to go file-by-file, and not commit-by-commit. There's really not that much code to review within the compiler.
So on my end, I can
How does that sound?
@abeln - it might be useful for you to be aware of #4004. Current status quo is that