Comment by SimonPStevens | Hacker News Reader

Comment by SimonPStevens | Hacker News Reader

I feel like I've been waiting for non-nullable reference types for forever.

What they talk about here, with explicit nullable reference types is so close but stumbles at the last hurdle. Having some kind of opt in on the compiler that makes regular references non-nullable is great for new projects (and arguably the best thing for the language itself), but leaves all legacy code out in the dark. You can't switch on a compiler option like this on any big existing project without massive effort. (And massive effort means management approval and planning and justification)

They got the case by case opt on the wrong part of the feature. It's really the non-nullability of a reference that's most important to be able to be opted in to on a case by case basis. (And case by case opt in means low effort, so it doesn't need big up front approval or planning, you just get on and write better code with fewer bugs.)

What's really needed is something like this

    String! s = null;

Where the ! makes the s reference non-nullable, so any attempt to assign null (or anything that could be null) to it is a compiler error.

And it's so disappointing because he comes so so close to that at the end with his talk of s!. as a way to say that you know something is not null, but it just doesnt quite get the benefit right.

It's non-nullability of reference types that should be the central feature here.

I'm just really hoping that these guys know what they are doing, and it's just he couldn't explain the subtleties in a short video, and this is going to turn out working the right way in the end.

At first we did think of this as a way to add non-nullable reference types to C#, maybe with a `string!` syntax as you propose.

The feature only really started to gel when we realized the important feature was nullable reference types. The thing is, in most code, most things aren't actually supposed to be null. So we want non-null to be the default.

When you start marking the things that should be null as such, you'll be protected from dereferencing those without a check. That's what actually prevents you from getting null-reference exceptions!

And once you've marked them all (usually a fraction of your type annotations), null really doesn't have a place in the remaining spots, and you can turn on the non-null check to eradicate those.

This leaves you with the smallest number of places to update your existing code, and leaves new code the cleanest.

You make a good point, although personally my codebase is split into enough projects that I think the transition will be manageable.

If it's just a compiler warning (and you don't treat warnings as errors) then can't you leave it on and do the work gradually? Or turn it on for a day, do some work, and turn it off again? You have to eat the elephant somehow.

Also, even if you make the non-nullability opt-in on a case-by-case basis, don't you still need a compiler switch to turn on occasionally and see what remains to be done?

The problem with that approach is that if you have it there, people will forget to use it, and still end up with tons of nullable references that really should be non-nullable. In order to be effective at catching bugs, non-nullability has to be opt-out rather than opt-in.

Yes, this sucks for existing code. I suspect that we'll get some kind of file-level switch, so that you can port things one class at a time - there's no reason why that switch has to have the same value for all files in the project.

No reason why there can't be both. Syntax to opt in one at a time for old projects, and a compiler option for new projects.

Yeah, or a file level switch would do, that would be fine. As long as there is some way of transitioning a project little bit at a time.

I hope we get one of those options

Reply on news.ycombinator.com