[DynamicCast] Rework existential casting discussion #33797
Merged
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
A previous PR collected the various existential types into a single section of the document. This PR takes advantage of that structure to clarify the discussion of existential and protocol casting: * Adds a general discussion of existential casting * Introduces the "strong existential invariant" and "weak existential invariant" that are common to all existential types * Makes a more precise distinction between protocols and existential types This last point involves a number of careful wording nuances based on the following: * A "protocol" is a syntactic construct defining a collection of requirements and default implementations (the latter via "protocol extensions") * Some protocol definitions (those without associated types or `Self` references) have an associated "protocol witness" existential type * A protocol witness existential type has the same name as the protocol definition from which it is derived but they are conceptually different notions * Existential types such as `Any`, `AnyObject`, and `Error` are not protocols -- for example, they cannot be extended. * `AnyHashable` is a type-erased container type but is not an existential. It does however behave like an existential for casting purposes.
|
Thanks to @slavapestov for his earlier comment about protocols being things that can be extended. That observation helped me a lot to clarify the language here. |
Jumhyn
reviewed
Sep 4, 2020
| Caveat: | ||
| Protocols that have `associatedtype` properties or which make use of the `Self` typealias cannot be used as independent types. | ||
| As such, the discussion below does not apply to them. | ||
| Any protocol definition (except those that include an `associatedtype` property or which makes use of the `Self` typealias) has an associated existential type named after the protocol. |
There was a problem hiding this comment.
@theblixguy This doc should be updated when that constraint is lifted!
|
Note: The discussion in PR #33735 is also relevant here. |
|
@swift-ci Please smoke test and merge |
1 similar comment
|
@swift-ci Please smoke test and merge |
|
Smoke tests still failing in |
|
@swift-ci Please smoke test and merge |
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.
A previous PR collected the various existential types into a single section of the document.
This PR takes advantage of that structure to clarify the discussion of existential and protocol casting:
This last point involves a number of careful wording nuances based on the following ideas:
Selfreferences) have an associated "protocol witness" existential typeAny,AnyObject, andErrorare not protocols -- for example, they cannot be extended.AnyHashableis a type-erased container type but is not an existential. It does however behave like an existential for casting purposes (thanks to special handling in both compiler and runtime), so it's described with the true existential types.