I don't disagree with you. But the fact is that the perfect word, "optional", has already been taken and a compromise would be needed (assuming there is a feature worth debating here).
We don't have an inverse of Optional -- why would we need an inverse of Required? The only objection to Required I can think of is actually that it sounds like the inverse of Optional, which it isn't.
Maybe it was confusing when I wrote "the other way around". If we consider: - Required = always there - Opposite of it = never there ("missing"?) - Optional = sometimes there I didn't mean the opposite/inverse, I meant "sometimes there". Anyway, I don't think it's a problem. Required/optional is common terminology, and pretty self-explanatory even to non-native English speakers. Theoretically, `Missing` would be needed if you wanted to declare a Typescript-like interface: class MyThing(TypedDict): [key: str]: int denied: Missing ...which would allow arbitrary key pairs but not field with `denied` as key. But, this is highly theoretical, I don't think there's use case. So yes, I agree that inverse of "required" is not needed. Why I am after something else than your earlier proposal of: class MyThing(TypedDict, total=False): req1: Required[int] opt1: str req2: Required[float] ...is that people _expect_ it to work the other way around. It feels more natural if the stuff you define is expected to exist, and you then mark up what differs from that. That's how ~everything else already works and I would say that's how our brain are already tuned.
opt1: ~str
I think this would read as "inverse of string" (strictly) or "not string" (in a more loose sense), rather than as "perhaps not there"?