[swift-evolution] Improved value and move semantics

Dave Abrahams dabrahams at apple.com
Wed Aug 3 15:48:25 CDT 2016

on Wed Aug 03 2016, Matthew Johnson <swift-evolution at swift.org> wrote:

>> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> on Tue Aug 02 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:
>>>> On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>> If it says that, it's... not quite right.  There are things we could do
>>>> to make some value copies more optimal.  For example, any value type
>>>> containing multiple class references—or multiple other value types (such
>>>> as arrays or strings or dictionaries) that contain class references—will
>>>> cost more to copy than a single class reference does.  At the cost of
>>>> some allocation and indirection, we could reduce the copying cost of
>>>> such values.  It's an optimization we've considered making, but haven't
>>>> prioritized.  
>>>> You can put a CoW wrapper around your value to do it manually.  I hacked
>>>> one up using ManagedBuffer for someone at WWDC but I don't seem to have
>>>> saved the code, sadly.
>>> Slightly off-topic, but one day I would like to see `indirect` turned
>>> into a generalized COW feature:
>>> * `indirect` can only be applied to a value type (or at least to a
>>> type with `mutating` members, so reference types would have to gain
>>> those).
>>> * The value type is boxed in a reference type.
>>> * Any use of a mutating member (and thus, use of the setter) is
>>> guarded with `isKnownUniquelyReferenced` and a copy.
>>> * `indirect` can be applied to an enum case with a payload (the
>>> payload is boxed), a stored property (the value is boxed), or a type
>>> (the entire type is boxed).
>>> Then you can just slap `indirect` on a struct whose copying is too
>>> complicated and let Swift transparently COW it for you. (And it would
>>> also permit recursive structs and other such niceties.)
>> My vision for this feature is:
>> a. We indirect automatically based on some heuristic, as an
>>   optimization.
>> b. We allow you to indirect manually.
>> c. We provide an attribute that suppresses automatic indirection to
>>   whatever depth possible given resilience boundaries.
> This all sounds great.  Does any of this fit into Swift 4 (either
> phase 1 or phase 2)?  It seems like at least the automatic part would
> have ABI impact.

Yes.  In principle, all of it has the potential to fit in Swift 4.  I'm
not sure what will actually happen of course.


More information about the swift-evolution mailing list