As Timur suggested, using attributes would give similar guarantees.
Although attributes are encouraged to give warnings rather than errors.
In terms of detecting locks, I am unsure what swift's atomics
equivalents are, but I think issuing test and/or CAS calls to atomics
are probably good clues.
Other people know more than me.

On 7/01/2022 2:31 pm, Sophia Poirier wrote:
> What is particularly compelling to me in this Swift proposal is making it a compile error, rather than a tooling issue (static analyzer or other build-chain analysis) as I have always seen this topic discussed. Granted, this also comes with some limitations when it is at the language level. @noAllocation is simple, though, it is very straight-forward draw a path to the system allocator.
>
> @noLocks is a more complex proposition. The fact that it can analyze locks that the compiler will introduce is very valuable, though, and something that a static analyzer that is not intertwined with the specific compiler cannot necessary guarantee. Beyond that, I am unsure how the Swift compiler is going to recognize something as a "lock". It can identify anything that boils down to a system primitive that is recognized as a lock. Recognizing a locking mechanism implemented entirely in user-space custom code (e.g. a simple spin-lock) is not as straight-forward. There also is the question of when the locking mechanism reaches down to scheduler wakes and yields vs when it does not. We know that in the former case, even a try_lock becomes an unknown-bounds operation.
>
> And then there are I/O operations as well.
>
> But... very intriguing direction to consider, I think.
>
> - Sophia
>
>
>> On Jan 6, 2022, at 3:28 PM, Matt Bentley <mattreecebentley_at_[hidden]> wrote:
>>
>> Similar to what Timur was suggesting in this talk:
>> https://youtu.be/G3qOKiPf1WQ?t=4906
>>
>> On 7/01/2022 12:01 pm, Sophia Poirier via SG14 wrote:
>>> intriguing direction: https://forums.swift.org/t/performance-annotations/54441
>>> _______________________________________________
>>> SG14 mailing list
>>> SG14_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14