Fixing C's Biggest Mistake

[FeepingCreature]

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.*