WUFFS is an example of a language which just doesn't have any of these "illegal/invalid objects".
Safe Rust doesn't have any either, though presumably you'll say "but unsafe" there.
> It is generally desirable to keep invalid objects properly typed
As written this doesn't mean anything, if the object is properly typed then it is valid, an invalid object can't be properly typed. So more likely you're imagining something like Rust's MaybeUninit<T> type wrapper which says well, either this is a T, or it isn't (yet) and so a programmer will need to tell the compiler once they've arranged that it is a T so then it can be used as a T.
Barry Revzin has (I think) landed the fixes to the C++ type system so that you could reasonably write this in C++ too once you have C++ 26.
It is impossible not to have invalid objects in a real-world system with i/o and dynamic memory allocation. Perhaps there is some semantic confusion between us, however. What you consider an invalid object doesn't exist in my parlance. I'm not even sure I understand what you mean by it. What I mean by an invalid object is an object or structure of a certain type that is in an unexpected state, a state does not allow further regular computation with it. It's some sort of error state.
For example: Dynamic memory allocation can fail. Input might fail. Input validation might fail. Hence, any object with dynamically allocated memory and any object processing input might become invalid in that sense.
You have to deal with such cases in any programming language and the source of error is the same in any of them. Nil is not an "additional source of error" or anything like that. Inadequate typing of nil (instead of having option types) might create an additional source of error but that depends on the language and it doesn't need to.
On a side note, those type system fixes may be neat for people who like typed logics but they are mostly pointless because the invalid state occurs at runtime.
What's happened is that you've been poisoned so badly by languages like C that you no longer even understand what's actually going on.
Your world becomes a bewildering mess in which it seems as though nothing can ever be trusted, and so you stumble into either writing endless checks because you're never sure of anything, or you throw your hands in the air and pronounce doing nothing "good enough" then blame others when inevitably your software doesn't work.
Yes, our allocation might fail, and in this case our result is Err(AllocError). That's a perfectly good result, and a perfectly good allocation error. It's not the memory you wanted, because your allocation failed, but it's not "invalid" in any useful sense.
WTF? I don't even program in C - but I do know Rust (and Ada). Being a little bit less condescending would go a long way if you want to be taken seriously. So much for the tone.
To address the content: Yes, you have to deal with that error result just like you have to deal with a nil pointer. No difference. That's the point.
By the way, the toxic behavior of the Rust community is one of the reasons why I barely use the language.
Even if you don't know C its influence has clearly poisoned your thinking about this issue.
The whole point of the billion dollar mistake is that the null pointer isn't actually a pointer, we would not have a type which is "Either a String or, sometimes just for fun the integer 19" because that's silly, so we shouldn't have a type which is "Either a pointer to T or, sometimes just not".
The huge difference is that if you don't make this mistake you only have to care about that "it wasn't a pointer" case when it might not be a pointer. Once you've handled that you're done, but with the C-style pointer that Tony's lecture is about you can't tell whether that was done, at every point in the program if you see a pointer maybe it is null.
In both Rust and Ada the type system is strong enough to express this. It is very silly to pretend that Err(AllocError) is invalid, it's not invalid at all, maybe that value wasn't what you were hoping for but it's entirely valid.
Safe Rust doesn't have any either, though presumably you'll say "but unsafe" there.
> It is generally desirable to keep invalid objects properly typed
As written this doesn't mean anything, if the object is properly typed then it is valid, an invalid object can't be properly typed. So more likely you're imagining something like Rust's MaybeUninit<T> type wrapper which says well, either this is a T, or it isn't (yet) and so a programmer will need to tell the compiler once they've arranged that it is a T so then it can be used as a T.
Barry Revzin has (I think) landed the fixes to the C++ type system so that you could reasonably write this in C++ too once you have C++ 26.