-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[concurrency] Implement effectful properties #36430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
eac2332
to
7a418ab
Compare
c43a4bc
to
3a1d7a0
Compare
@swift-ci please smoke test |
5e5dac7
to
9f36726
Compare
@swift-ci please smoke test |
9f36726
to
e3fc0d7
Compare
@swift-ci please smoke test and merge |
e3fc0d7
to
d28e031
Compare
@swift-ci please smoke test and merge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read through this and don't have any substantial comments, which means I should read through it again... but that shouldn't block merging.
d28e031
to
4d248bb
Compare
@swift-ci please smoke test and merge |
This is the PR that I learn about |
4d248bb
to
68e50f9
Compare
@swift-ci please smoke test and merge |
68e50f9
to
292b927
Compare
@swift-ci please smoke test and merge |
Just the driver failure on Linux... will try again because that should be fixed by now. |
@swift-ci please smoke test Linux |
An effectful 'get' accessor must be the only accessor for the property.
With effectful properties, we'll now raise an error if an effect specifier appears on a non-'get' accessor.
The basic rule is that the protocol requirement describes the maximal set of effects that the property is allowed to have. Thus, witnesses must have the same or fewer effects specifiers on the getter. For class inheritance overrides, you can remove effects freely, as long as you stay within the bounds of the normal override restrictions. But, you cannot override with more effects than the base member has. Same goes for protocol member overrides. Furthermore, we disallow key paths to effectful properties/subscripts, which also cannot be @objc.
They're currently incompatible, but it should be possible to enable this, with some care taken to ensure that effectful wrappers are composed correctly.
292b927
to
8ba98a9
Compare
OK I rebased and fixed the change to the asyncHandler note. Rerunning test locally before triggering another run |
@swift-ci please smoke test and merge |
https://forums.swift.org/t/pitch-effectful-read-only-properties/44090
TODOs:
-Xfrontend -enable-experimental-concurrency
flag@objc
(causes crashes in typechecking, for good reason)Deferred Tasks:
u.someProp
fromA
should be chosen due to being in anasync
context:Note that the checker disallows conformance to
A & None
with anasync
property witness, so this does not ultimately lead to a mis-compile. It is, however, a bit misleading to allow someone to writef
as it stands, and doesn't match up with how we handle this for functions.