None of the prior proposals require regex parsing or runtime evaluation of annotations.
Without regex parsing or runtime evaluation of annotations, how can `TypedDict` metaclass know that a field is required or not? Especially when using `from __future__ import annotations` (aka. PEP 563)? Using `get_type_hints` is not a solution, because it prevents declaring recursive `TypedDict`. `dataclass` decorator has the same issue, and it solves it using regex parsing. IMO runtime evaluation of annotation are better here (in the typing module, private API like `_eval_type` is available), but I don't see an other way of doing this.
NamedTuple's assignment syntax is used for specifying default values, not potentially-missing items.
If you understand `...` in `TypedDict` context as a kind of javascript `undefined`, comparison with `NamedTuple` can be done.
It's not clear to me how field assignment would convey "this item is potentially-missing". If anything it says "there's something here but I'm not specifying what".
Or maybe it can says "the value of this key can be undefined".
The assignment-based syntax was intentionally made less-capable that the class-based syntax to encourage folks to migrate to the class-based syntax. There's no reason to update it.
Could we consider to have a `make_dataclass` function that is outdated compared to `dataclass` decorator. I don't think so, and this can apply here too. Anyway, to continue on the consistency subject, `dataclasses` module use field value to store field metadata. We could consider something like ```python class MyDict(TypedDict): key: int = typed_dict_key(required=False) ``` but I think `...` shortcut is simpler. Joseph Perez