Yes, Emacs and Remacs do the same thing. All Lisp values are tagged pointers, and a nil gets encoded as a zero value with a zero tag. It's simple and easy to ch

Yes, Emacs and Remacs do the same thing. All Lisp values are tagged pointers, and a nil gets encoded as a zero value with a zero tag. It's simple and easy to check for, and you won't have any problems as long as you always remember to do so. However, this is not a Lisp value; it's a pointer to one. Specifically, it's a pointer to memory set aside to store a specific Lisp variable's value. Leaving it zeroed makes no sense, because eventually someone is going to store a value in there and it'll have to be allocated anyway. Better to do that all in one large block, rather than a thousand tiny ones. Even if we wanted to lazily allocate these, we can't leave a simple Rust reference (or pointer) null past the end of the unsafe block. Rust does have an Option type, and if you use it on a type that isn't nullable, then the compiler will use the zero value for None variant and all other values for the Some. Since references can never be null, an Option<&T> will always take up the same amount of space as a &T; there's no additional overhead. At some point, when enough of the C code is ported to Rust, I'm sure we'll start using this to represent all Lisp values and a Lisp nil will always be a Rust None.