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

Matthew Johnson matthew at anandabits.com
Mon May 16 11:21:35 CDT 2016

> On May 15, 2016, at 2:01 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> on Fri May 13 2016, Matthew Johnson <matthew-AT-anandabits.com <http://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.

Fair enough.  Although in most contexts people don’t use the word when discussing the 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.

In many cases this is true - you don’t need more than value semantics as you define it.  However it is not at all true that PureValue is never necessary for the correctness of code.  I’m going to provide an example to the contrary below.

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

The piece that matters here is state management.  The core concept is to tightly control how mutations happen.  It is modeled in terms of state type T, an initial value t, an action type A (instances of which are mutation commands, as in the command pattern), and a reducer function (T, A) -> T which produces a new state.

Here’s a toy implementation that is somewhat simplistic but captures the essence of the concept:

class Store<State, Action> {
    typealias Reducer = (State, Action) -> State
    var stateHistory: [State]
    let reducer: Reducer
    init(initialState: State, reducer: Reducer) {
        stateHistory = [initialState]
        self.reducer = reducer
    func applyAction(action: Action) {
        let newState = reducer(stateHistory.last!, action)
    var currentState: State {
        return stateHistory.last!
    var canUndo: Bool {
        return stateHistory.count > 1
    func undo() {
        if canUndo {

This design relies on State being a PureValue.  The whole idea is that the only way any path of observation rooted at currentState can change is when the reducer returns a new state when it is called by `applyAction`.  That guarantee cannot be provided by value semantics alone under your definition of value semantics.  Further, each state in the history is intended to be a static snapshot of the “currentState” state at a specific point in time.  All states should be logically independent from each other and from anything anywhere else in the program.  This cannot be guaranteed under your definition of value semantics.  

If we allow State to be Array<MyMutableReferenceType> which has value semantics under your definition it is clear that we should have no expectation that the desired properties are preserved.  The Store class is fundamentally broken if it can be used with State types that are not pure values.

I’m not sure why it didn’t occur to me sooner, but this strategy for managing app state is very similar in nature to what Sean Parent discusses in his value semantics talk (https://www.youtube.com/watch?v=_BpMYeUFXv8 <https://www.youtube.com/watch?v=_BpMYeUFXv8> and related https://www.youtube.com/watch?v=bIhUE5uUFOA <https://www.youtube.com/watch?v=bIhUE5uUFOA>). 

Sean discusses using value semantics to model applications state (he calls it document).  His examples don’t use reified actions and reducer functions so it is a bit different but it relies on the same pure value semantics.  The demo he gives in the talk is a toy example modeled on the design Photoshop uses to implement its history feature.  This design relies on each document in the history being an aggregate which is a PureValue.  This is not an academic discussion, but on with real world practical utility.

Sean says “value semantics is similar to functional programming, except objects still have addresses and in-situ operations…  You're trying to maintain the ability to locally reason about your code but you're not denying the fact that the machine has memory and you can do in-situ operations on it”.  Towards the end he quotes from a discussion he had with John Backus (inventor of FP).  John said: “it always annoyed me that FP and the no side effect way of programming had become a religion.  With FP I was trying to come up with a mathematically rigorous way to program and I understood the complexities of having side effects.  I always knew we had to deal with side effects, I just wanted a structured way to do it.”  John agreed that Sean’s approach to value semantics provides such a structure.  Allowing shared mutable references throws away that structured approach.  (As an aside, this is the most exciting thing about value semantics IMO - it provides a structured approach to side effects, allowing local reasoning about code).  

Sean gives an example of how references break the ability to reason locally where he has two shared_ptrs that point to the same object:

"If you look at it in terms of just the individual types you kind of do have value semantics.  When I copy a shared pointer it copies the pointer with value semantic operations...  The problem is the references.  When I'm looking at a shared_ptr I'm looking at it as if I have the object.  So really what I have is two objects that intersect.  So really my object in the program is this whole connected mess.  At any particular point in code I have difficulty reasoning about the whole thing.  The shared structure breaks our ability to reason locally about code."

Sean makes an important distinction between looking at individual types and looking at the aggregate as a whole.  It is very important to him that the entire aggregate be logically independent as this facilitates local reasoning.  This is exactly what I have been calling a pure value.  Pure value never allows any intersection to be observed (immutable intersections are allowed because they cannot be observed, which Sean alludes to in passing).  Incidentally, it is pretty clear from the talk that immutable intersection is heavily used in Photoshop history in order to keep memory use reasonable.  This falls into the category of persistent data structures.

My impression is that Sean’s definition of "value semantics” excludes “intersecting objects” (where the intersection is mutable) and is aligned with John’s “full value semantics” and the notion of “pure value” we have been discussing.  


> -- 
> -Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160516/151abe1e/attachment.html>

More information about the swift-evolution mailing list