Skip to content
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

[0410-atomics] Mention the 'let–only' behavior of Atomic is gated behind a flag #2306

Closed
wants to merge 1 commit into from

Conversation

MahdiBM
Copy link
Contributor

@MahdiBM MahdiBM commented Feb 6, 2024

This has rightfully caused a bit of confusion for some folks: https://forums.swift.org/t/var-of-atomic-type-is-not-an-error/69885

@@ -1051,7 +1051,7 @@ class Counter {

By declaring this variable as a `var`, we opt into Swift's dynamic exclusivity checking for this property, so all non-exclusive accesses incur a runtime check to see if there is an active exclusive (e.g. mutating) access. This inherently means that atomic operations through such a variable will incur undesirable runtime overhead -- they are no longer purely atomic. (Even if the check never actually triggers a trap.)

To prevent users from accidentally falling into this trap, `Atomic` (and `AtomicLazyReference`) will not support `var` bindings. It is a compile-time error to have a `var` that has an explicit or inferred type of `Atomic`.
To prevent users from accidentally falling into this trap, `Atomic` (and `AtomicLazyReference`) will not support `var` bindings. It is a compile-time error to have a `var` that has an explicit or inferred type of `Atomic`. This behavior is gated behind the `StaticExclusiveOnly` exprimental feature flag.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm...going forward, the intended design isn't that this enforcement will require an experimental feature flag, so we probably shouldn't write it as such here I think. Rather, now that the proposal is accepted, one would think the behavior should (eventually) stop being gated behind a flag.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree to be honest, I'd be more happy if it's simply taken out of the flag gate. Considering the attribute is an additive change, having it enabled by default doesn't come with drawbacks as far as I know.

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Feb 6, 2024

Apparently Alejandro will be fixing this problem, so i'll close this PR.

@MahdiBM MahdiBM closed this Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants