It's unsafe. It's needed for crucial performance reasons. For example, the only way to pass an array in recursive function without copying the array struct itself on each call is only by passing it as an unsafe pointer. When you have thousands of calls at a time this is extremely valuable tool to have. Real life example is concurrent rendering of scene objects in some scene represented by a tree. Each call is escaping via Dispatch.concurrentPerform, while guaranteed thread safe because each call modifies predefined region of the memory in that given array. In this case passing array as inout argument will result in additional and unnecessary retain/release of underlying _storage is the underlying array buffer, will it not?
I understand that Chris Lattner has literally zero influence on the language nowadays, but let's not forget that one of the swifts original purpose is to be a systems programming language:
- In the systems programming context, it is important for Swift developers to have low-level opt-in access to something like the C or C++ memory consistency model. This is definitely interesting to push forward, but is orthogonal to this work.
I'd like to have this as an opt-in mechanism via simple operator, not with another @-attribute on the other side of API call.
We are also working on addressing memory sharing ergonomics in pure Swift, as laid out in this roadmap.
This looks great. Lets have buffer views before making this source breaking change. Why this proposal is not a "future direction" of buffer view proposal?