[SE-0335] Introduce existential any#40282
Conversation
@swift-ci please build toolchain |
This comment has been minimized.
This comment has been minimized.
hborlaforce-pushed the existential-any branch 2 times, most recently from 55d48d3 to 15fb6bbCompare This comment has been minimized.
This comment has been minimized.
hborlaforce-pushed the existential-any branch 2 times, most recently from a00f954 to f90f614Comparehborlaforce-pushed the existential-any branch 3 times, most recently from e83c521 to 00841a5Compare@swift-ci please build toolchain |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
hborlaforce-pushed the existential-any branch 5 times, most recently from c578fc8 to eb29776Comparehborla changed the title anyany
to enable the 'any' keyword.
existential type spelled with `any`.
@swift-ci please build toolchain |
@swift-ci please smoke test |
hborla changed the title anyany This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The new type, called ExistentialType, is not yet used in type resolution. Later, existential types written with `any` will resolve to this type, and bare protocol names will resolve to this type depending on context.
explicit existential types are enabled. Note that existential metatypes still resolve to ExistentialMetatypeType, but later this type can be replaced with ExistentialType(MetatypeType).
…ed()" This reverts commit eb1bd07.
…kUnsupportedProtocolType()" This reverts commit 15f88e9.
flip the return value in the implementation accordingly.
requirements to be spelled with 'any' when explicit existential types are enabled.
…lType when explicit existentials are enabled.
existential types are enabled.
existential types enabled.
@swift-ci please build toolchain |
@swift-ci please smoke test |
Linux Toolchain (Ubuntu 16.04) Install command |
| case TypeReprKind::Existential: | ||
| return { }; | ||
There was a problem hiding this comment.
Should this not recurse into the constraint repr?
There was a problem hiding this comment.
I believe so, but today it probably doesn't matter since we don't allow writing things like extension any P or any other construct that uses this code path.
| if (auto meta2 = type2->getAs<ExistentialMetatypeType>()) { | ||
| ExistentialMetatypeType *meta2; | ||
| if (auto existential = type2->getAs<ExistentialType>()) { | ||
| meta2 = existential->getConstraintType()->getAs<ExistentialMetatypeType>(); |
There was a problem hiding this comment.
This seems superfluous: we already have an early return for ExistentialMetatypeType in ExistentialType::get.
There was a problem hiding this comment.
Yeah, some of these are redundant now (I wrote this code before I made ExistentialType::get return early for some of the types that aren't "supported" yet in my follow up PR). I'm holding off on doing major cleanups on main, including making all of the code paths only operate on ExistentialType, in case I need to cherry-pick bug fixes to release/5.6.
There was a problem hiding this comment.
Thank you for letting me know!
in case I need to cherry-pick bug fixes to
release/5.6
FYI, the following code is miscompiling on main. Looks like we're parsing any in the initializer as a decl ref.
protocolP{associatedtypeA}do{letmeta:(anyP).Type =(anyP).self }There was a problem hiding this comment.
Thanks! Here's the fix: #40949
Implementation for SE-0335 Introduce existential
any.The feature is currently behind the frontend flag
-enable-explicit-existential-types.Resolves: rdar://86032280