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

[Dave Abrahams]

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.

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