[SE-0335] Introduce existential any
#40282
Conversation
|
@swift-ci please build toolchain |
This comment has been minimized.
This comment has been minimized.
hborla
force-pushed
the
existential-any
branch
2 times, most recently
from
55d48d3 to
15fb6bb
Compare
This comment has been minimized.
This comment has been minimized.
hborla
force-pushed
the
existential-any
branch
2 times, most recently
from
a00f954 to
f90f614
Compare
hborla
force-pushed
the
existential-any
branch
3 times, most recently
from
e83c521 to
00841a5
Compare
|
@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.
hborla
force-pushed
the
existential-any
branch
5 times, most recently
from
c578fc8 to
eb29776
Compare
hborla
changed the title
anyany
hborla
force-pushed
the
existential-any
branch
from
eb29776 to
00bf9a9
Compare
to enable the 'any' keyword.
existential type spelled with `any`.
hborla
force-pushed
the
existential-any
branch
from
00bf9a9 to
8da6c0d
Compare
|
@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.
hborla
force-pushed
the
existential-any
branch
from
8da6c0d to
760ed45
Compare
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.
hborla
force-pushed
the
existential-any
branch
from
760ed45 to
8db129b
Compare
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.
protocol P {
associatedtype A
}
do {
let meta: (any P).Type = (any P).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