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

[Matthew Johnson]

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?  Wouldn't the compiler be able to do this in the automatic implementation in some cases (such as writing to a stored var)?  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?

> 
> -- 
> -Dave