The return of None-aware operators for Python

And the typing cannot express some things, for example a function that takes T as a parameter and returns an instance of T as a result… there's been an issue open since years to support this, but in general it isn't supported.

Because of Python's laissez-faire multi-paradigm attitude, it's actually quite difficult to design a good implementation of None-aware operators. You can't really use the Rust solution, because Python is dynamically-typed and likes to signal errors with exceptions rather than sentinel values (i.e. you can't reasonably define it to propagate Result<V, E> or the like, since Result is not even a thing in Python). But the TypeError or ValueError that you tend to get from None is usually the wrong exception to throw, and propagating None as if it was NaN will make it difficult to get a traceback. The idiomatic behavior, in some cases, is to eagerly check for None and raise an exception.

Maybe this syntax could work?

x = y ?? raise FooError('y should not be None.')

But that is going to be problematic. Raise is a statement, not an expression, so you'd need to make a special case to allow it in this one context, or you'd need to convert it into an expression. And then people will also want to write x = y ?? z, so you need to allow for that as well.

I have no idea how this is supposed to be extended for ?. and ?[], because where are you supposed to put the raise?

Let's make our own, custom user-defined generic sum type we'll call it Perhaps<T> and it'll have two values, Huh, and Well(T). Ours works exactly the same way and sure enough the Huh value of Perhaps<&T> will also be represented by an all-zeroes bit pattern.

This behaviour is guaranteed by the language (it is named the Guaranteed Niche Optimisation and is crucial to the language's design) but similar behaviours are delivered in practice for more exotic arrangements. For example Rust's char type needs 4 bytes, but it only handles Unicode "scalar values" (basically think codepoints unless you really care about the minutia of Unicode) so there are a *lot* of unused values. Accordingly, a sum type with Tafkap, SimpsonsMeme and Other(char) will fit in the same 4 bytes as the char alone, because Rust will just squeeze Tafkap and SimpsonsMeme in as bit patterns which aren't valid for char. You aren't promised this will work, but the Rust compiler is going to do it anyway because it's faster and smaller and easy.

† Rust only "really" has one loop, the one introduced by the keyword loop. But for and while both work fine, because the compiler just transforms them into loops, this "de-sugaring" is actually spelled out in the documentation, and the de-sugaring of for (since it's a modern iterator for-each not a C-style for) needs all of IntoIterator, Iterator, Some and None - and so they have to be langitems, annotated core library features which must exist or the language won't work.

In Python things are very different, None is a completely different type than whatever you expected, just as the null pointer is a distinct type in C++.