For comparison, D's @nogc attribute would be semantically similar to noAllocations.
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@gmail.com> 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@lists.isocpp.org
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14