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

[Matthew Johnson]

> 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.  Similar considerations apply to simpler wrapper structs such as Weak.

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.  

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