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

[Matthew Johnson]

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

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

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

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

Cool.  Not trying to push for it now.  Hopefully it has a chance in Swift 4.

> 
> -- 
> -Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160516/41bcd53e/attachment.html>