[swift-dev] Pure/isUniquelyReferenced and C libraries

[davesweeris at mac.com]

Speedups are Very Good, but IMHO undefined behavior is Very Very Bad. How hard would it be for the compiler to detect this? If so, would it be possible to throw a warning or something and revert to the slower path if someone calls isUniquelyReferenced?

> On Feb 2, 2016, at 13:03, Michael Gottesman via swift-dev <swift-dev at swift.org> wrote:
> 
> Background
> ==========
> 
> I have recently been thinking about clang attributes and how we can take advantage of the work other people have done in terms of putting attributes in their headers especially in terms of ARC.
> 
> The two most pervasive such attributes are the const/pure attributes. Trivially the const attribute (since it can not read global memory) can not read or write reference counts. But what about pure? For those who are unfamiliar pure in "c" means that a function's value is only dependent on its arguments and reading global memory. Being able to only read global memory is an interesting property from the ARC perspective since there is only one ARC function that reads a reference count that is exported from the runtime, the uniqueness check. All other ways to read/write a reference count are either restricted to pure swift code or if they are allowed in C++ code write to reference counts. If we were able to say that it is undefined behavior to invoke isUniquelyReferenced from non-swift runtime functions, we immediately could get nice speed boosts when using imported c code that is pure without any further work on the maintainers part.
> 
> Proposal
> =======
> 
> State that is is undefined behavior to reference isUniquelyReferenced in a non-swift function in 3rd party libraries.
> 
> Thoughts?
> Michael
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160202/0b46f08a/attachment.html>