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