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

[David Sweeris]

> On May 5, 2016, at 5:01 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Wed May 04 2016, David Sweeris <davesweeris-AT-mac.com> wrote:
> 
>>> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 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. 
>> 
>> You mean that a struct's properties would have to have value
>> semantics, too? 
> 
> Either that, or you'd have to implement CoW, or you'd not use the
> storage behind any properties that were references in a way that affects
> value semantics.
> 
>> I think I'm okay with that, especially if it's done through new types
>> of structs/enums.
> 
> New types of structs/enums?  What does that mean?
I meant leave `struct` and `enum` the way they are, and introduce a `different_struct` and `different_enum` (placeholder names, of course) which enforced the “no reference-semantics” rules.

I’m inclined to think we should adopt your “no reference-semantics” rule, but I’m not entirely sure what the impact would be. Adding new types side-steps the issue, at the cost of increasing the complexity of the language/compiler. I’m unsure if that'd be a worth-while trade-off.

- Dave Sweeris