Well, looks like the GP missed a very common false fact:

The operations written in a program must literally represent the operations the computer will execute.

This one stops being true on high-level languages at the level of x86 assembly.

It is possible to write complex and performant programs without allocating memory.

And in some languages, where you only operate on values, and never worry about where something is stored, allocation is just an implementation detail.

That's... not true?

Example in C:

void fun(void) {

    int a[16];

    for (int i = 0; i < sizeof(a); i++)
    {
        a[i] = 1;
    }

}

I have allocated and referred to memory without pointers here.

A few of those myths are stated as fact in the aforementioned thread.

> Well, clearly there is a need for a special value that is not part of the set of legal values.

There's a neat trick available here: If you make zero an illegal value for the pointer itself, you can use zero as your "special value" for the std::optional wrapper, and the performance overhead goes away.

This is exactly what Rust does, and as a result, Option<&T>, Option<Box<T>>, etc are guaranteed to have zero overhead: https://doc.rust-lang.org/std/option/index.html#representati...

> If I can dream, all of this would be solved by 72-bit CPUs, which would be the same as 64-bit CPUs, but the upper 8 bits can be used for garbage collection tags, sentinel values, option types etc.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...

Address space is 64bit, pointers are 128bit, and encode the region the pointer is allowed to dereference. And there's a secret 129th bit that doesn't live in the address space that gets flipped if the pointer is overwritten (unless it's an explicit instruction for changing a pointer)