PEP 712: Update with suggestions/clarifications from discussion (#3496)

peps/pep-0712.rst

@@ -93,6 +93,9 @@ Example
 
 .. code-block:: python
 
+  def str_or_none(x: Any) -> str | None:
+    return str(x) if x is not None else None
+
   @dataclasses.dataclass
   class InventoryItem:
       # `converter` as a type (including a GenericAlias).
@@ -209,11 +212,42 @@ users of converters are likely to encounter. Such pitfalls include:
 * Forgetting to convert values in the bodies of user-defined ``__setattr__`` in
   non-frozen dataclasses.
 
+
+Additionally, potentially confusing pattern matching semantics should be covered:
+
+.. code-block:: python
+
+    @dataclass
+    class Point:
+        x: int = field(converter=int)
+        y: int
+
+    match Point(x="0", y=0):
+        case Point(x="0", y=0):  # Won't be matched
+            ...
+        case Point():  # Will be matched
+            ...
+        case _:
+            ...
+
+However it's worth noting this behavior is true of any type that does conversion
+in its initializer, and type-checkers should be able to catch this pitfall:
+
+.. code-block:: python
+
+  match int("0"):
+    case int("0"):  # Won't be matched
+        ...
+    case _:  # Will be matched
+        ...
+
 Reference Implementation
 ========================
 
 The attrs library `already includes <attrs-converters_>`__ a ``converter``
-parameter containing converter semantics.
+parameter exhibiting the same converter semantics (converting in the
+initializer and on attribute setting) when using the ``@define`` class
+decorator.
 
 CPython support is implemented on `a branch in the author's fork <cpython-branch_>`__.