[5.7] Diagnose Availability for Parameterized Existential Types #58766
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Usages of parameterized existential types that involve runtime type metadata to resolve must be gated on the appropriate OS version in which those features have landed. This means the following usage classes must appear gated:
- Checked casts (is, as?, as!)
- As arguments to generic types (Foo<any P<T>>)
- As type witnesses to protocol conformances
- In erasure expressions (and optional-to-any erasure expressions)
- In metatypes
- Tuples
What does this leave?
- Concrete usages
- any P<T> as a parameter or result type
- Any amount of optional types around existential types
- Static casts (as)
It's worth calling out the fact that usages of parameterized existential types in tuples are banned but usages in struct members are not. This is due to the fact that Tuple identity and runtime layout is determined by a metadata query against each component type. Whereas for a struct, the opaque type layout does not depend upon the type metadata of the fields at runtime, and the identity of the struct is determined nominally rather than structurally.
Practically, this means that one can work around the lack of tuples by defining a struct with an equivalent type structure as fields:
struct AdHocEraser { var x: any P<T> }
rdar://92197245
|
@swift-ci test |
hborla
approved these changes
May 12, 2022
|
⛵ |
AnthonyLatsis
added
🍒 release cherry pick
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry pick of #58655
Usages of parameterized existential types that involve runtime type metadata to resolve must be gated on the appropriate OS version in which those features have landed. This means the following usage classes must appear gated:
Foo<any P<T>>)What does this leave?
any P<T>as a parameter or result typeIt's worth calling out the fact that usages of parameterized existential types in tuples are banned but usages in struct members are not. This is due to the fact that Tuple identity and runtime layout is determined by a metadata query against each component type. Whereas for a struct, the opaque type layout does not depend upon the type metadata of the fields at runtime, and the identity of the struct is determined nominally rather than structurally.
Practically, this means that one can work around the lack of tuples by defining a struct with an equivalent type structure as fields:
rdar://92197245