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

Dave Abrahams dabrahams at apple.com
Fri May 13 09:19:55 CDT 2016


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”

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

-- 
-Dave


More information about the swift-evolution mailing list