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

[Dave Abrahams]

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

> Sent from my iPad
>
>> On May 13, 2016, at 9:12 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>>> on Mon May 09 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>>> 
>>>    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.
>> 
>> It's an algorithm, or if the configuration is declarative, there's an
>> algorithm that manipulates it.  That said, I still don't have a concrete
>> example of how view configuration can depend on these properties.
>
> The algorithm might just be "copy x bit of data to y view property,
> etc".  That is so trivial that it feels like a stretch to call it an
> algorithm.

Algorithms can be trivial.

> That "algorithm" doesn't depend on this property because it executes
> at a single point in time.  However, a view controller might depend on
> that property in order to render properly across time (for example,
> configuring cells as they scroll on and off screen).

The example is too abstract for me to understand.

Let me put this differently: I recognize that your concept of
“PureValue” may be a *sufficient* condition for some generic
algorithm/component to work, but it is never a *necessary* condition,
because genericity (or use of a superclass or protocol type) erases
details of the actual types involved from the point of view of the
algorithm/component.  It doesn't matter if your type contains a class
reference if it has value semantic properties.  My claim is that
PureValue is an overly-restrictive constraint that makes many things
less useful than they should be.

> This property allows us to separate values from non-local mutation and
> make such separation a requirement.  Rather than observing mutations
> of objects with KVO, etc we might prefer to observe something that
> provides a new aggregate value instead, while requiring the entire
> aggregate value itself to be (observably) immutable at all times
> (because we stored it with a let property locally).  This can make it
> easier to reason about correct behavior of your code.  But it doesn't
> work unless all visible parts of the aggregate are immutable.
>
>  If you're not familiar with Elm, Redux, etc it might be worth taking
>  a look.  

That's a pretty broad link.  At which parts do you think I should look?

-- 
-Dave