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

[Dave Abrahams]

on Wed May 04 2016, Matthew Johnson <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.

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

> 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