Proposing std.typecons : Optional (with PR) + rant

[Nick Treleaven]

On Tuesday, 11 June 2019 at 13:55:52 UTC, FeepingCreature wrote:
> On Tuesday, 11 June 2019 at 12:30:10 UTC, aliak wrote:
>> (as mentioned, the range thing is not the only problem - 
>> another big one is treating null as a valid value for classes).
>
> That's a fundamental problem with D though. Null *is* a valid 
> value for classes.

It is accepted but it is not valid. There is no object there, you 
can't dereference it (unless null is a valid memory address, 
which it is in some cases). Null is a gaping hole in any static 
type system.

Rant:
IMO the worst thing Walter ever said was "Non-nullable pointers 
are just plugging one hole in a cheese grater":
https://twitter.com/walterbright/status/338821357762654208

Optional types with language enforcement can allow a static 
guarantee that any data is constructed with particular values, 
returning an optional that is none when the initializer was 
outside those values.

I'd actually rather have language-assisted optional types than 
features like function overloading (a convenience feature, 
sometimes abused), because it means *the type system can model 
runtime checks as a static type guarantee*. They are a game 
changer.

> Making a class type optional just means that you're adding 
> *another* type that also means "absent" at a different level of 
> abstraction.

Re-use null to mean absent.

> Was it the right decision to allow null in class types? Who 
> knows. (No.) But I don't think that's a decision that should be 
> patched in library types.

Then I vote against including your Optional.