{"id":37751,"date":"2022-11-29T16:12:00","date_gmt":"2022-11-29T21:12:00","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=37751"},"modified":"2022-11-29T16:12:00","modified_gmt":"2022-11-29T21:12:00","slug":"introduction-to-move-only-types-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/11\/29\/introduction-to-move-only-types-in-swift\/","title":{"rendered":"Introduction to Move-Only Types in Swift"},"content":{"rendered":"

Tim Kientzle<\/a>:<\/p>\n

I thought it would help to have an informal sketch to help outline why move-only types are interesting, clarify a few subtle points (like what “move” really means), and briefly explain some of the issues we’ll need to tackle in order to bring this to Swift.<\/p>\n

[…]<\/p>\n

So the first step in bringing move-only support to Swift is to add operations with different lifetime-management behaviors. This will include constructs such as for borrow x in collection<\/code> that let you iterate over the items in a collection without requiring an implicit copy and f(take x)<\/code> that explicitly invalidates the local value as part of passing it into a function. We’re also exploring variations of these that would allow you to temporarily gain mutable access to a value. These would allow you to efficiently mutate an element “in place” in various scenarios, which is a useful optimization tool for copyable values and an essential prerequisite for move-only values.<\/p>\n

[…]<\/p>\n

By making Any<\/code> a synonym for any Copyable<\/code>, we can ensure that Any<\/code> is itself always copyable at the cost of limiting it to only store copyable values. This redefinition would preserve the behavior of current code that uses Any<\/code>. Of course, this means we need to introduce a new type that can hold any value whether it is copyable or not.<\/p><\/blockquote>\n\n

Previously:<\/p>\n