✏️ Fix typo: implementor -> implementer

typing_doc.md

@@ -101,9 +101,9 @@ where the attribute `documentation` contains the same value string passed to the
 
 ### Additional Scenarios
 
-The main scenarios that this proposal intends to cover are described above, and for implementors to be conformant to this specification, they only need to support those scenarios described above.
+The main scenarios that this proposal intends to cover are described above, and for implementers to be conformant to this specification, they only need to support those scenarios described above.
 
-Here are some additional edge case scenarios with their respective considerations, but implementors are not required to support them.
+Here are some additional edge case scenarios with their respective considerations, but implementers are not required to support them.
 
 #### Type Alias
 
@@ -127,7 +127,7 @@ def hi(to: Username) -> None: ...
 def hi(to: Annotated[str, doc("The name of a user in the system")]) -> None: ...
 ```
 
-Nevertheless, implementors would not be required to support type aliases outside of the final type annotation to be conformant with this specification, as it could require more complex derefrenecing logic. If they do, they could state they also support the optional type aliases.
+Nevertheless, implementers would not be required to support type aliases outside of the final type annotation to be conformant with this specification, as it could require more complex derefrenecing logic. If they do, they could state they also support the optional type aliases.
 
 #### Annotating Type Parameters
 
@@ -139,7 +139,7 @@ def hi(to: list[Annotated[str, doc("The name of a user in a list")]]) -> None: .
 
 ...the documentation in `doc()` would refer to what it is annotating, in this case, each item in the list, not the list itself.
 
-There are currently no practical use cases for documenting type parameters, so implementors are not required to support this scenario to be considered conformant, but it's included for completeness.
+There are currently no practical use cases for documenting type parameters, so implementers are not required to support this scenario to be considered conformant, but it's included for completeness.
 
 #### Annotating Unions
 
@@ -153,7 +153,7 @@ def hi(to: str | Annotated[list[str, doc("List of user names")]]) -> None: ...
 
 In particular, the documentation would not refer to a single string passed as a parameter, only to a list.
 
-There are currently no practical use cases for documenting unions, so implementors are not required to support this scenario to be considered conformant, but it's included for completeness.
+There are currently no practical use cases for documenting unions, so implementers are not required to support this scenario to be considered conformant, but it's included for completeness.
 
 #### Duplications
 
@@ -163,9 +163,9 @@ If `doc()` is used multiple times in a single `Annotated`, it would be considere
 def hi(to: Annotated[str, doc("A user name"), doc("A pet name")]) -> None: ...
 ```
 
-Implementors can consider this invalid and are not required to support this to be considered conformant.
+Implementers can consider this invalid and are not required to support this to be considered conformant.
 
-Nevertheless, as it might be difficult to enforce it on developers, implementors can opt to support one of the `doc()` declarations.
+Nevertheless, as it might be difficult to enforce it on developers, implementers can opt to support one of the `doc()` declarations.
 
 In that case, the suggestion would be to support the first one (just to simplify that implementation, as that would be the first one to be found when iterating over the `Annotated` parameters).