On Friday, 30 December 2022 at 02:03:39 UTC, Walter Bright wrote:
>On 12/29/2022 12:45 PM, Adam D Ruppe wrote:
>The alternative is the language could have prevent this state from being unanticipated at all, e.g. nullable vs not null types.
It can't really prevent it. What happens is people assign a value, any value, just to get it to compile. I've seen it enough to not encourage that practice.
If there are no null pointers, what happens to designate a leaf node in a tree? An equivalent "null" object is invented. Nothing is really gained.
This all hangs together if you have a sufficient type system. What you'd do in Neat (with non-nullable objects) is, for instance, you'd start with a non-nullable type, by default, say Class class
, you'd get an error that "null is not convertible to Class" or such, and you'd either declare the variable/field as nullable Class
(which doesn't implconv to Class), if it's a variable declare it as mut uninitialized Class class
(which is easy to grep for), or if it's in a data structure add a leaf case as (Class | :none)
- but then you're obligated to handle :none
at every use site; the compiler won't get you get to Class
otherwise. That can be as simple as .case(:none: die)
, which tbf is not much better than a segfault, but at least the termination happens in the right location, rather than some random time later on an access attempt. The point is that you don't get automatically opted into crashes by the language, but have to choose them explicitly. You can get null crashes by telling the compiler to crash in case of null, but you can't get null crashes by forgetting about null.