PEP 695: Incorporated recent feedback from python-dev. (#2713)
Co-authored-by: Eric Traut <erictr@microsoft.com>
This commit is contained in:
parent
897fd51371
commit
5e0be8f86f
28
pep-0695.rst
28
pep-0695.rst
|
@ -754,6 +754,30 @@ were less clear. Also, this syntax did not interact well with class and
|
||||||
function decorators, which are common in Python. Only one other popular
|
function decorators, which are common in Python. Only one other popular
|
||||||
programming language, C++, uses this approach.
|
programming language, C++, uses this approach.
|
||||||
|
|
||||||
|
We likewise considered prefix forms that looked like decorators (e.g.,
|
||||||
|
``@using(S, T)``). This idea was rejected because such forms would be confused
|
||||||
|
with regular decorators, and they would not compose well with existing
|
||||||
|
decorators. Furthermore, decorators are logically executed after the statement
|
||||||
|
they are decorating, so it would be confusing for them to introduce symbols
|
||||||
|
(type parameters) that are visible within the "decorated" statement, which is
|
||||||
|
logically executed before the decorator itself.
|
||||||
|
|
||||||
|
|
||||||
|
Angle Brackets
|
||||||
|
--------------
|
||||||
|
Many languages that support generics make use of angle brackets. (Refer to
|
||||||
|
the table at the end of Appendix A for a summary.) We explored the use of
|
||||||
|
angle brackets for type parameter declarations in Python, but we ultimately
|
||||||
|
rejected it for two reasons. First, angle brackets are not considered
|
||||||
|
"paired" by the Python scanner, so end-of-line characters between a ``<``
|
||||||
|
and ``>`` token are retained. That means any line breaks within a list of
|
||||||
|
type parameters would require the use of unsightly and cumbersome ``\`` escape
|
||||||
|
sequences. Second, Python has already established the use of square brackets
|
||||||
|
for explicit specialization of a generic type (e.g., ``list[int]``). We
|
||||||
|
concluded that it would be inconsistent and confusing to use angle brackets
|
||||||
|
for generic declarations but square brackets for explicit specialization. All
|
||||||
|
other languages that we surveyed were consistent in this regard.
|
||||||
|
|
||||||
|
|
||||||
Bounds Syntax
|
Bounds Syntax
|
||||||
-------------
|
-------------
|
||||||
|
@ -1043,7 +1067,7 @@ Rust uses declaration-site variance, and variance of type parameters is
|
||||||
typically inferred from their usage. In cases where a type parameter is not
|
typically inferred from their usage. In cases where a type parameter is not
|
||||||
used within a type, variance can be specified explicitly.
|
used within a type, variance can be specified explicitly.
|
||||||
|
|
||||||
Rust provides no way to specify a default type argument.
|
A default type argument can be specified using the "=" operator.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
|
@ -1149,7 +1173,7 @@ Summary
|
||||||
+------------+----------+---------+--------+----------+-----------+-----------+
|
+------------+----------+---------+--------+----------+-----------+-----------+
|
||||||
| Swift | <> | T: X | | | decl | inferred |
|
| Swift | <> | T: X | | | decl | inferred |
|
||||||
+------------+----------+---------+--------+----------+-----------+-----------+
|
+------------+----------+---------+--------+----------+-----------+-----------+
|
||||||
| Rust | <> | T: X, | | | decl | inferred, |
|
| Rust | <> | T: X, | | = | decl | inferred, |
|
||||||
| | | where | | | | explicit |
|
| | | where | | | | explicit |
|
||||||
+------------+----------+---------+--------+----------+-----------+-----------+
|
+------------+----------+---------+--------+----------+-----------+-----------+
|
||||||
| Kotlin | <> | T: X | | | use, decl | inferred |
|
| Kotlin | <> | T: X | | | use, decl | inferred |
|
||||||
|
|
Loading…
Reference in New Issue