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

[Dave Abrahams]

on Mon May 16 2016, Matthew Johnson <swift-evolution at swift.org> wrote:

>> 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).

I have no problem with adding some support for doing this manually, but
IMO the compiler *should* do it automatically for some value types.
Maybe an attribute could be used to add manual control.

-- 
-Dave