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

[Matthew Johnson]

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.

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

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.  

> 
> -- 
> -Dave