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

Matthew Johnson matthew at anandabits.com
Thu May 5 21:03:37 CDT 2016

> On May 5, 2016, at 4:59 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> on Wed May 04 2016, Matthew Johnson <matthew-AT-anandabits.com <http://matthew-at-anandabits.com/>> wrote:
>>    On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution
>>    <swift-evolution at swift.org> wrote:
>>    on Wed May 04 2016, Matthew Johnson <swift-evolution at swift.org> wrote:
>>                On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution
>>            <swift-evolution at swift.org> wrote:
>>            on Wed May 04 2016, Adrian Zubarev <swift-evolution at swift.org>
>>            wrote:
>>                    Not sure what to think about the enum cases inside a
>>                protocol (if AnyEnum would
>>                even exist), it could be a nice addition to the language, but
>>                this is an own
>>                proposal I guess.
>>                We should start by adding AnyValue protocol to which all value
>>                types
>>                conforms.
>>            Having a way to constrain conformance to things with value semantics
>>            is
>>            something I've long wanted. *However*, the approach described is too
>>            simplistic. It's possible to build classes whose instances have
>>            value
>>            semantics (just make them immutable) and it's possible to build
>>            structs
>>            whose instances have reference semantics (just put the struct's
>>            storage
>>            in a mutable class instance that it holds as a property, and don't
>>            do
>>            copy-on-write). 
>>            In order for something like AnyValue to have meaning, we need to
>>            impose
>>            greater order. After thinking through many approaches over the
>>            years, I
>>            have arrived at the (admittedly rather drastic) opinion that the
>>            language should effectively outlaw the creation of structs and enums
>>            that don't have value semantics. (I have no problem with the idea
>>            that
>>            immutable classes that want to act as values should be wrapped in a
>>            struct). The language could then do lots of things much more
>>            intelligently, such as correctly generating implementations of
>>            equality.
>>        That is a drastic solution indeed! How would this impact things like
>>        Array<UIView>? While Array itself has value semantics, the aggregate
>>        obviously does not as it contains references which usually be mutated
>>        underneath us. 
>>    Value semantics and mutation can only be measured with respect to
>>    equality. The definition of == for all class types would be equivalent
>>    to ===. Problem solved.
>>        Similar considerations apply to simpler wrapper structs such as Weak.
>>    Same answer.
>> Hmm. If those qualify as “value semantic” then what kind of structs and enums
>> would not? A struct wrapping a mutable reference type certainly doesn’t “feel”
>> value semantic to me and certainly doesn’t have the guarantees usually
>> associated with value semantics (won’t mutate behind your back, thread safe,
>> etc).
> Sure it does.
>     public struct Wrap<T: AnyObject> : Equatable {
>       init(_ x: T) { self.x = x }
>       private x: T
>     }
>     func == <T>(lhs: Wrap<T>, rhs: Wrap<T>) -> Bool {
>       return lhs.x === rhs.x
>     }
> I defy you to find any scenario where Wrap<T> doesn't have value
> semantics, whether T is mutable or not.
> Alternately, you can look at the Array implementation.  Array is a
> struct wrapping a mutable class.  It has value semantics by virtue of
> CoW.

This goes back to where you draw the line as to the “boundary of the value”.  Wrap and Array are “value semantic” in a shallow sense and are capable of deep value semantics when T is deeply value semantic.  Both have their place, but the maximum benefit of value semantics (purity) is derived from deep value semantics.  This is when there is no possibility of shared mutable state.  This is an extremely important property.

let t = MyClass()

In this example, foo had better not depend on the wrapped instance not getting mutated.

>>        My expectation is a generic aggregate such as Array would have to
>>        conditionally conform to AnyValue only when Element also conforms to
>>        AnyValue.
>>        I’m also wondering how such a rule would be implemented while still
>>        allowing for CoW structs that *do* implement value semantics, but do
>>        so while using references internally.
>>    I am not talking about any kind of statically-enforceable rule, although
>>    we could probably make warnings sophisticated enough to help with this.
>> You said the you have arrived at the opinion that the language should
>> “effectively outlaw” structs and enums that do not have value semantics. That
>> sounded like static enforcement to me. 
> The language outlaws certain kinds of inout aliasing without providing static
> enforcement.  This is like that.

I did not know this.  Now you have me curious.  Can you give an example of where we are able to violate law?  I ask mostly because it sounds like there is a possibility of stumbling into dangerous territory, possibly without being aware that you have done so.

>> Maybe you meant we should allow the compiler to assume value semantics
>> for structs and enums despite the fact that it doesn’t statically
>> enforce this?
> That would be one *consequence* of effectively outlawing it.  The library
> could make similar assumptions.
>>        If the compiler can be sophisticated enough to verify value semantics
>>        statically maybe it would be better to have that mechanism be
>>        triggered by conformance to AnyValue rather than for all structs and
>>        enums. Types that conform to AnyValue would receive the benefits of
>>        the compiler knowing they have value semantics, while other uses of
>>        structs and enums would remain valid. Best practice would be to
>>        conform structs and enums to AnyValue whenever possible.
>>        Another possible advantage of this approach would be allowing
>>        immutable reference types to conform to AnyValue and receive the
>>        associated benefits such as the generated implementation of equality,
>>        etc.
>>        -Matthew
>>            -- 
>>            Dave
>>            _______________________________________________
>>            swift-evolution mailing list
>>            swift-evolution at swift.org
>>            https://lists.swift.org/mailman/listinfo/swift-evolution
>>        _______________________________________________
>>        swift-evolution mailing list
>>        swift-evolution at swift.org
>>        https://lists.swift.org/mailman/listinfo/swift-evolution
>>    -- 
>>    Dave
>>    _______________________________________________
>>    swift-evolution mailing list
>>    swift-evolution at swift.org
>>    https://lists.swift.org/mailman/listinfo/swift-evolution
> -- 
> Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160505/444dc7ba/attachment.html>

More information about the swift-evolution mailing list