{"id":27624,"date":"2019-12-19T14:44:26","date_gmt":"2019-12-19T19:44:26","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=27624"},"modified":"2019-12-19T14:46:36","modified_gmt":"2019-12-19T19:46:36","slug":"swift-evolution-pitch-modify-accessors","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/12\/19\/swift-evolution-pitch-modify-accessors\/","title":{"rendered":"Swift Evolution Pitch: Modify Accessors"},"content":{"rendered":"

Ben Cohen<\/a>:<\/p>\n

\n

We propose the introduction of a new keyword, modify<\/code>, for implementing mutable computed properties and subscripts, alongside the current get<\/code> and set<\/code>.<\/p>\n

The bodies of modify<\/code> implementations will be coroutines, and they will introduce a new contextual keyword, yield<\/code>, that will be used to yield a value to be modified back to the caller. Control will resume after the yield<\/code> when the caller returns.<\/p>\n

This modify<\/code> feature is currently available (but not supported) from Swift 5.0 as _modify<\/code>, for experimentation purposes when reviewing this proposal.<\/p>\n

[…]<\/p>\n

We cannot yield the value in the array’s buffer directly because it needs to be placed inside an optional. That act of placing inside the optional creates a copy.<\/p>\n

We can work around this with some lower-level unsafe code. If the implementation of Array.first<\/code> has access to its underlying buffer, it can move that value directly into the optional, yield it, and then move it back[…] During the yield to the caller, the array is in an invalid state: the memory location where the first element is stored is left uninitialized, and must not be accessed. This is safe due to Swift’s rules preventing conflicting access to memory<\/a>.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n