Respond to Eric's comments

Author: Gobot1234

pep-0696.rst

@@ -21,6 +21,12 @@ Abstract
 This PEP introduces the concept of type defaults for TypeVars, which act
 as defaults for a type parameter when none is specified.
 
+Default type argument support is available in some popular languages
+such as C++, TypeScript, and Rust. A survey of type parameter syntax in
+some common languages has been conducted by the author of :pep:`695`
+and can be found in its
+:pep:`Appendix A <695#appendix-a-survey-of-type-parameter-syntax>`.
+
 Motivation
 ----------
 
@@ -201,8 +207,8 @@ Constraints
 ~~~~~~~~~~~
 
 For constrained ``TypeVar``\ s, the default needs to be one of the
-constraints. It would be an error even if it is a subtype of one of the
-constraints.
+constraints. A type checker should generate an error even if it is a
+subtype of one of the constraints.
 
 .. code:: py
 
@@ -213,8 +219,24 @@ Function Defaults
 ~~~~~~~~~~~~~~~~~
 
 The ``TypeVar``\ 's default should also be compatible with the
-parameter's runtime default if present. But they are erased to
-not have defaults when called.
+parameter's runtime default if present, if they aren't a type checker
+should generate an error.
+
+.. code:: py
+
+   def foo(x: DefaultIntT = 12345): ...  # Valid
+   def foo(x: DefaultIntT = "bar"): ...  # Invalid: expected an int for default, got str
+
+The defaults are erased when called so, they act like they have no default.
+
+.. code:: py
+
+   def baz(y: DefaultIntT) -> DefaultIntT: ...
+   # equivalent to
+   def baz(y: T) -> T: ...
+
+   reveal_type(bar(67890))    # type is int
+   reveal_type(bar("hello"))  # type is str
 
 Implementation
 --------------
@@ -387,6 +409,9 @@ convenient, could have a ``TypeVar`` with no default follow a
    class Foo(Generic[T, U]):
        ...
 
+This would have also been a breaking change for a small number of cases
+where the code relied on ``Any`` being the implicit default.
+
 Acknowledgements
 ----------------