Swift Prospective Vision: Accessors
John McCall (forum):
However, this approach has significant problems. The biggest is that the
getaccessor has to return an independent value. If the accessor is just returning a value stored in memory, which is very common for data structures, this means the value has to be copied.[…]
This vision document lays out the design space of accessors for the next few years, as Swift continues to advance its support for non-
Copyableand non-Escapabletypes. It explains Swift’s basic access model and how it may need to evolve. It explores what developers need from accessors in these advanced situations. Finally, it discusses different kinds of accessors, both existing and under consideration, and how they do or do not fit into the future of the language as we see it.[…]
The
yieldaccessor is the natural most-general model of a borrowing read access. It is a coroutine function which yields a borrowed value and can then do arbitrary finalization when resumed.The
borrowaccessor is a specialization of that model which expresses that no finalization is required. It is an ordinary function that returns a borrowed value.[…]
yield inoutandmutateare both modification accessors.[…]
unsafeAddressis functionally a borrowing read accessor. It is an ordinary function that returns anUnsafePointer<ValueType>.
Previously:
- Noncopyable Generics Walkthrough
- Swift Proposal: Init Accessors
- Swift Proposal: Noncopyable Structs and Enums
- Introduction to Move-Only Types in Swift
- Roadmap for Improving Swift Performance Predictability
- Swift Evolution Pitch: Modify Accessors
1 Comment RSS · Twitter · Mastodon
At least they're consistent: trying to find complex solutions to weird problems of their own making, neither of which are things that I've ever had to care about even one iota in my 35+ year career.
Fortunately I no longer find it frustrating. Now it's just amusing watching them spin around in imaginary problems of their own making.
