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

[Matthew Johnson]

> On May 19, 2016, at 5:07 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Mon May 16 2016, Matthew Johnson <swift-evolution at swift.org <mailto: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.

You’re saying when we have support for indirect value types the compiler should do it automatically for some of them right?  If that’s what you mean then yes, I agree.  The compiler should do it automatically for simple value types (i.e. when the right thing is obvious).

> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160519/720ff169/attachment.html>