[swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson]

> On May 16, 2016, at 10:14 AM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Mon May 16 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
> 
>>> On May 15, 2016, at 1:53 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>> 
>>> 
>>> on Fri May 13 2016, Matthew Johnson <matthew-AT-anandabits.com <http://matthew-at-anandabits.com/>> wrote:
>>> 
>>>>>> If we’re going to hide the implementation details maybe it’s worth
>>>>>> taking advantage of the type by making the props var and using CoW.
>>>>>> 
>>>>>> What do you think about a proposal to enhance “indirect” for value
>>>>>> types and / or instances of them.  I can think of a few approaches to
>>>>>> this that we could consider.  I would be much more comfortable with
>>>>>> what you want to do if we tackle that as well.
>>>>> 
>>>>> It's a good idea that can help to make CoW easy to implement; I have
>>>>> advocated for it (not in public) in the past.  
>>>> 
>>>> Glad to hear this.  Maybe in Swift 4?  (I know it's too early to say)
>>>> 
>>>>> People should be aware
>>>>> that the resulting automatic CoW will be suboptimal in many cases,
>>>>> because when you discover you need new storage it's usually better to
>>>>> build a new value than to copy the old one and overwrite it.
>>>> 
>>>> How big a difference does that usually make, especially when compared
>>>> to the reasons you would use indirect in the first place?  
>>> 
>>> Usually a big difference.
>>> 
>>>> Wouldn't the compiler be able to do this in the automatic
>>>> implementation in some cases
>>> 
>>> Not in any interesting cases I know of.  If you're inserting into an
>>> array and you discover you need new storage because there is more than
>>> one reference, starting by copying can double the cost of the insertion
>>> (on a large array when memory allocation is fast).
>> 
>> Of course this is true of data structures.  I wouldn’t expect the
>> compiler to provide a reasonable implementation of CoW for data
>> structures.
>> 
>> Maybe I wasn’t clear.  I was talking about domain model objects like the following:
>> 
>> struct Person {
>>  var firstName: String
>>  var lastName: String
>>  // …
>> }
>> 
>> I find it hard to believe the compiler CoW implementation would do
>> something so suboptimal as to be significant when you write to
>> firstName through an indirect instance in cases like this (which are
>> pervasive in application code).
> 
> Oh, OK.  And you want to CoW this because...?  Reducing refcount
> traffic?

Avoiding copying and refcounting.  This might be a large aggregate.  You might use indirect structs and CoW so that portions of the aggregate can be shared by more than one aggregate root (i.e. persistent data structure).

> 
>>>> (such as writing to a stored var)?
>>> 
>>> I don't know what you mean here.
>> 
>> Continuing with the previous example, if the CoW implementation is
>> significantly better when using a memberwise initializer to construct
>> the new box rather than copy the value over from the old box and then
>> update the property that was written to it seems like the compiler
>> should be able to make that optimization in some cases.  (i.e. when
>> there exists a memberwise initializer which exposes all stored
>> properties).
> 
> Sure.
> 
> -- 
> -Dave