[mrkeen]

> First, the null pointer is essentially inevitable if you want to model the world, which has references (things containing denotations of other things).

I took major exception to this. The real world doesn't have non-things, and references do not demand to refer to non-things.

If your domain does actually have the concept of null, just make a type for it. Then you won't accidentally use a 6 or a "foo" where a null was demanded.

[zabzonk]

And I would just add:

Do we want to model the "real world"? This seems to hark back to that long-forgotten world of "animal-cat-dog" OO programming.

[ninalanyon]

I spent the bulk of my career modelling a small part of the real world and OOP absolutely has a place in that.

[karmakaze]

Tony Hoare himself said that it wasn't needed in the type system he'd created. He added it because it was so easy to do so and couldn't resist the temptation.

OTOH seeing undefined method 'blah' for nil:NilClass isn't really any better.

[NovemberWhiskey]

The real world is full of relationships that may or may not exist. What’s the referent of “my spouse” if I’m unmarried?

Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

[mrkeen]

> What’s the referent of “my spouse” if I’m unmarried?

* It's the same referent as all the other things you don't have. Your struct has a Spouse, why does it not also have a RivieraChateau, a SantaClaus, BankAccountInSwissFrancs. If you can answer why you left those out, you know why to leave out Spouse.

* Why stick to 0-1 Spouses. As soon as you do that you're gonna need n Spouses, where some of them will have an ex- flag set, married from&to timestamps.

> Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

* It shouldn't make a difference whether it's a pointer or a reference or a value or a class. If you believe null is one of the Integers, you should also believe that null is one of the ints. Why should your domain change to accommodate C idioms.

[ratorx]

Making it explicit wouldn’t be particularly problematic no? Option<&Spouse> in Rust terms. Or for this specific case, a GADT (Single | Married<&Spouse>)?

It could even use a special “NULL” address. Just don’t pollute every type with it.

[adrian_b]

Polluting every type with it is just a very bad implementation which has nothing in common with the concept of NULL as proposed by Tony Hoare in the paper "Record Handling".

The concept as proposed by Hoare is strictly necessary for things like partial relations, which are encountered very frequently in practice.

It is true however that a large number of programming languages have misused the concept of a NULL reference proposed by Hoare.

As you say, there must be distinct types that may have or may not have a "nothing" value.

[mrkeen]

> The concept as proposed by Hoare is strictly necessary for things like partial relations

I read the 'Partial Functional Relationships' section. There's nothing special there. It's just structs with nulls.

> Polluting every type with it I think you're reacting to the pollution of the syntax. Hoare already polluted the semantics: Every type can be null. You can't even model a NonNull<Spouse> because NonNull itself can be null.

[elviejo]

Another example a web link that points to a page that no lnger exists.

It's a null pointer exception.

[death_eternal]

You're clearly wrong.