3 ms·
Its a footgun, but one chosen for practicality. There have been a number of other nullability annotation frameworks for java in the past that are more complete
by UncleMeat 2y ago
Its a footgun, but one chosen for practicality. There have been a number of other nullability annotation frameworks for java in the past that are more complete and correct, but also more difficult to use and understand for a typical developer. A classic example is "what about nullness of fields defined in constructors?" After all, there is a real moment in program execution where those fields store nulls. So people try to add things to represent "nullable, but once non-null it remains non-null forever" or whatever and then people don't practically use the system because it is too much conceptual complexity.
- lolinder 2y agoAnother practical answer is to just accept that an edge case like that is one we won't completely solve for. Kotlin will yell at you if you don't initialize everything in the constructor and will yell at you if you try to use a variable in the constructor before it's declared, but if you call out to another function in the constructor you're on your own and might end up with nulls. That's not complicated to understand, but it eliminates most types of not-yet-initialized nulls in the language. Also, isn't how you handle not-null types in constructors totally orthogonal to which syntax is used for not-null and whether there's a third I-dunno-if-null type? And is a three-way nullability system really simpler to understand?