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

[Dave Abrahams]

on Fri May 13 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:

> Sent from my iPad
>
>> On May 13, 2016, at 9:19 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>>> on Mon May 09 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>>> 
>>>    Remember that the only value semantic reference types are immutable, so
>>>    the struct rendition of such types has only immutable properties.
>>>    Personally, I don't think that transforming
>>> 
>>>           struct X {
>>>             ...
>>>           private:
>>>             let prop1: Type1
>>>             let prop2: Type2
>>>             let prop2: Type3
>>>           }
>>> 
>>>    into
>>> 
>>>           struct X {
>>>              ...
>>>           private:
>>>             class Storage {
>>>               let prop1: Type1
>>>               let prop2: Type2
>>>               let prop2: Type3
>>>             }
>>>             let value: Storage
>>>           }
>>> 
>>>    is so awful if you find you need to optimize away some reference
>>>    counting manually; you just need to add “.value” to property accesses in
>>>    X's methods, and this doesn't require any forwarding.
>>> 
>>> It’s not too awful but it does expose implementation details.  
>> 
>> How?  All the changes are under “private”
>
> Sorry, I didn't notice private.  Probably because I am thinking of model types which expose their stored properties.
>
>>> 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).

> (such as writing to a stored var)?

I don't know what you mean here.

> Would it be possible to design indirect value types in a way that
> allows a transition to manual control of CoW without breaking calling
> code if that becomes necessary?

Sure, anything is possible in design, and in a feature like this I would
of course want that capability.  It isn't the right time (for me) to try
to figure it all out though :-)

-- 
-Dave