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

[Matthew Johnson]

> On May 8, 2016, at 12:51 AM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Sat May 07 2016, Matthew Johnson <matthew-AT-anandabits.com <http://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.

In many cases it may just be view configuration that depends on those properties.  I suppose you can call view configuration code an algorithm but I think that would fall outside of common usage.

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

I am also primarily interested in the programming model.  That said, as far as I can tell everything Andrew has said is talking about the exact same thing I am.  Andrew, if I have said anything that doesn’t align with the constraint you’re talking about please let me know!

> 
> 
> -- 
> -Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160509/2db5ec84/attachment.html>