I feel like you’re doing something wrong with the nullables… I’m pretty sure you don’t need to mark up files, you can just enable it on the whole project? I’m not sure about the attributes, you might have a point there, but it just makes sense for value vs reference types IMO, since value types are already implicitly different in terms of nullability.
But yeah, I can imagine it’s half-baked, since nullable reference types (that’s the name, previously reference types were just nullable by default with no extra features) are a more recent addition to the language, one that wasn’t built with them in mind.
If you create a new project from scratch, yes, you can enable it project-wide. If you have a project which has a bunch of code predates nullable reference types, and you enable it project wide, you’ll have a billion warnings about it. Also, they’re warnings and not errors by default, which just encourages developers to either ignore or suppress them.
So the reality is that you need to remember when you’re making new classes to add the attribute, and then deal with external stuff - which isn’t always clearly marked whether it’s nullable or not unless it’s using attributes, by the way… just such a total mess.
They should have just gone with something more like Rust’s “Option” type. Would have been clearer for codebases that have to deal with a mix. They also could have clearly and decisively deprecated non-nullable reference types and just told people they were going to remove support in some future version so we could all migrate to them properly like we’ve done for .NET Core/.NET 5+.
I feel like you’re doing something wrong with the nullables… I’m pretty sure you don’t need to mark up files, you can just enable it on the whole project? I’m not sure about the attributes, you might have a point there, but it just makes sense for value vs reference types IMO, since value types are already implicitly different in terms of nullability.
But yeah, I can imagine it’s half-baked, since nullable reference types (that’s the name, previously reference types were just nullable by default with no extra features) are a more recent addition to the language, one that wasn’t built with them in mind.
If you create a new project from scratch, yes, you can enable it project-wide. If you have a project which has a bunch of code predates nullable reference types, and you enable it project wide, you’ll have a billion warnings about it. Also, they’re warnings and not errors by default, which just encourages developers to either ignore or suppress them.
So the reality is that you need to remember when you’re making new classes to add the attribute, and then deal with external stuff - which isn’t always clearly marked whether it’s nullable or not unless it’s using attributes, by the way… just such a total mess.
They should have just gone with something more like Rust’s “Option” type. Would have been clearer for codebases that have to deal with a mix. They also could have clearly and decisively deprecated non-nullable reference types and just told people they were going to remove support in some future version so we could all migrate to them properly like we’ve done for .NET Core/.NET 5+.