[tialaramex]

It is in hindsight unfortunate that this idea didn't get into the CLR itself.

The blog post doesn't mention this, but whereas if I say my function only takes this 32-bit signed integer value type, a VB.NET caller can't hand it "null" because that's not a 32-bit signed integer - if instead I say it takes string (not the nullable string?) too bad, the VB.NET caller can just pass null anyway because in the CLR there's no distinction.

You're actually expected (if you provide public surface) to write a null test, in your C# code which explicitly says in the function signature that this mustn't be null, otherwise it might blow up at runtime because the CLR doesn't care.

[pjmlp]

Nullable types came into C# during the .NET Framework days, back when the team had very high bar to ever add features that would change the runtime as OS component.

Hence why async/await is such a mess of IL bytecode, as it was implemented in userspace so to say.

Only with .NET Core, they followed other languages in not tying the runtime to the OS, a lesson that Google also had to learn (ART is updatable via PlayStore since Android 12).