[swift-evolution] Improved value and move semantics

[Matthew Johnson]

> On Aug 3, 2016, at 3:48 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 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.

Of course. :)  

I asked mostly because I am wondering when it might be appropriate to start discussing these topics in more detail, and specifically if they fit into the first phase of Swift 4 whether we should start a thread now.

> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution