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

[Dave Abrahams]

on Sat May 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:

>> On May 7, 2016, at 3:03 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> on Sat May 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>> 
>>> This depends on the type. For types representing resources, etc it works just
>>> fine. But for models it does not work unless the model subgraph is entirely
>>> immutable and instances are unique. 
>>> I agree that it isn't a good idea to provide a default that will
>>> certainly be wrong in many cases.
>> 
>> Please show an example of a mutable model where such an equality would
>> be wrong.  
>
> This is somewhat orthogonal to the main points I have been making in
> this thread.  I have been focused on discussion about reference types
> that have value semantics and the distinction between value semantics
> and pure values.  In any case, here you go:
>
> let a: NSMutableArray = [1, 2, 3]
> let other: NSMutableArray = [1, 2, 3]
> let same = a === other // false
> let equal = a == other // true

That's not proof that an == for NSMutableArray that matches the behavior
of === would be wrong, just that it would be different from what we
currently have.  

> Reference equality does not match the behavior of many existing
> mutable model types.  You seem to be making a case that in Swift it
> should.  

Yes.

> But that is a separate discussion from the one I am trying to engage
> in because mutable reference types *do not* have value semantics.

Then maybe I should disengage here?

>>>        Okay then, what algorithms can you write that operate on PureValue that
>>>        don't work equally well on Array<AnyObject>?
>> 
>> You haven't answered this question.  How would you use this protocol?
>
> I answered elsewhere but I’ll repeat that one use that immediately
> comes to mind is to constrain values received in the initializer of a
> (view) controller to ensure that the observable state will not change
> over time.  

My claim is that substituting the constraint of “it has value
semantics,” while presumably looser than the PureValue constraint, would
not compromise the correctness of your view controller, so not only is
the meaning of PureValue hard to define, but it doesn't buy you
anything.  If you want to refute that, just show me the code.

> This is not an algorithmic use but is still perfectly valid IMO.

If the properties of PureValue matter to your view controller, there's
an algorithm somewhere that depends on those properties for its
correctness.

> If I read Andrew’s post correctly it sounds like it may also be of use
> to the optimizer in some cases.

FWIW, I'm only interested in how you use this protocol in the
programming model, and I'm not even sure Andrew is talking about the
same constraint that you are.


-- 
-Dave