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

[Tyler Fleming Cloutier]

> On May 4, 2016, at 3: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 <mailto: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.

Hmm, I get the feeling that I was arguing your own point back at you. Sorry, Dave, I’m a little slow. :)

Still, how would you generate an equality operator for a data structure that requires wrapper classes currently, like a LinkedList?

> 
>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160507/e0d02604/attachment.html>