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

[Dave Abrahams]

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

>> On May 22, 2016, at 3:42 PM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Sun May 22 2016, Matthew Johnson <swift-evolution at swift.org> wrote:
>> 
>>> What I am arguing for is the ability to distinguish aggregates which
>>> are logically isolated from aggregates which contain salient
>>> references to shared mutable state. 
>> 
>> Everything with value semantics is logically isolated in that way.
>
> Array<UIView> has salient references whose referent is shared mutable
> state.  The references are salient attributes. You’re saying the
> referent doesn’t matter because the boundary of the value stops at the
> reference.  

I'm saying you can define things that way, and it helps to make the
model for generic programming coherent.  Without something like this, it
becomes almost impossible to specify the behavior of generic components
in an understandable way without simultaneously preventing the use of
reference values as simple object identities, which *are* values.  As I
mentioned elsewhere, we could force users to wrap these reference values
to produce something that doesn't have easily identifiable reference
semantics, but the requirement of your `PureValue` that there should be
*no way* to derive access to the referenced instance from the wrapped
reference is too limiting.

> I’m saying it does matter in that it means the aggregate is no longer
> logically isolated because shared mutable state is reachable through
> the aggregate.  Therefore it is not isolated in that way that I was
> intending to describe.

This, again, is a matter of your mental model.  I do think it's
reasonable to say that—especially in Swift where reference-ness is often
syntactically invisible—asking people to adopt a mental model that
*directly* treats references as values is simply unrealistic.  In that
case, using some kind of wrapper to represent object identity might be
the only practical way to do this.

>>> To be honest, I am really struggling to understand why this
>>> distinction seems unimportant to you.
>> 
>> The non-exposure of shared mutable state is a hugely important
>> property of well-encapsulated design.  However, I don't believe it's
>> appropriate to represent that with a protocol, because I don't
>> believe there exist any generic components whose correctness depends
>> on it.
>
> Do you believe it is appropriate to represent this in some other way
> that allows us to state architectural intent and introduce constraints
> for the purpose of structuring a large code base?

Sure, if it makes your life better, you should define it; I just don't
see yet that it has any place in the standard library.  It is a
principle of generic programming that protocols (concepts) are
*discovered* through a specific process.  In the standard library, we
don't define a new protocol until we have identified a family of
concrete components that can be generalized based that protocol and
whose correctness depends on the protocol's constraints.

HTH,

-- 
-Dave