Null-checked reference types

[IchorDev]

On Wednesday, 7 August 2024 at 10:13:05 UTC, Quirin Schroll wrote:
> Reference types are nullable, yet most of the time, actual 
> references aren’t null and expected to be non-null.

Well that’s why associative arrays implicitly allocate 
themselves. I don’t think that would work for classes though…

> Prime example: `ref`. Can be null, never is expected to be in 
> practice, and when it happens to be null, it’s a bug. A bug not 
> by the language semantics, but in practical code. 100% of the 
> time.

Uh yeah… we should be preventing that.

> Instead of a contract or documentation saying they have to be 
> non-null, the best way is to have the type system enforce it at 
> compile-time. Just to mention two, Kotlin and Zig default to 
> non-nullable references / pointers. You have to annotate 
> nullable ones and handle the null case.

Interesting. Do people who use those languages actually like that?

>> Having nullability for value types might be nice too, but 
>> again it’s something you can already achieve in other ways.
>
> Yes, optionals, which aren’t great to use. Having worked with 
> C#, which has core-language nullable value types, I can tell 
> you, it makes it really nice to work with them. If an `indexOf` 
> function returns `size_t?` (or even better: some `index_t?` 
> which hooks into the null semantics so that it reserves 
> `size_t.max` for its null state), it’s clear that the case of 
> whatever you’re seeking might not be there as to be accounted 
> for.

Well there you go, maybe for value types we need something like 
the range interface but for nullability? And then for reference 
types can just do `is null`.