What is the reason that the state cannot be modelled as an immutable data structure?

[lo1tuma]

Hello 👋,

I wonder why the ReducerProtocol defines the state as a mutable inout parameter. I’ve used a lot of flux-inspired frameworks in past (mostly in the JS ecosystem) where the reduce function is supposed to return the new state value instead of mutating that parameter directly. So it should be function that gets the old/current state as an input an returns the new state as an output.

I know the current return value of reduce is an Effect and allows us to run side-effects. But I don’t really see this is a blocker, since we could also return a tuple (or a better data structure) that contains both, the new state and the effect.

[maksimn]

The return value as a tuple or a struct that contains the state and an effect looks clumsy.

[mbrandonw]

Hi @lo1tuma, Swift has a few features that Javascript does not have that makes this "mutation" completely safe, and even equivalent to return a whole new value.

First, Swift has values types, which are types that are copied when passed to function. This means if you copy the value and mutate it in your function, it did not make any changes to the original value passed to the function. That local mutation is completely quarantined to just the function.

This is in stark contrast to reference types (e.g. classes and essentially all of JS's types), in which objects are passed by their reference to functions. This means any change made to the object in the function is instantly visible to anyone else holding a reference to that object. Such mutations can affect objects in many parts of the application at once, and it can be difficult (if not impossible) to know who all will be affects.

So, that's one feature Swift has that JS doesn't. There's another one that pairs well with value types, and it's called inout. Since value types are copied when passed to functions, it is a very common pattern pattern to make a copy in the function, apply mutations, and then return that copy:

func doSomething(state: State) -> State {
  var state = state
  state.field = …
  …
  return state
}

Swift allows you to shorten that into its equivalent form using inout:

func doSomething(state: inout State) {
  state.field = …
  …
}

No need to specify a return type, no need to make a copy and no need to return the copy. These two forms are completely equivalent. One is no safer than the other thanks to Swift's value types. However, ergonomics wise, one is clearly better since the inout form allows you to perform less ceremony to make changes to the state.

[mbrandonw]

Hi @maksimn, that's not true. While it does mutate the value as far as the caller is concerned, the mutation is extremely limited and is not at all related to reference semantics as it is traditionally discussed.

First of all, the mutation is only visible to the caller of the function, no one else. And further the caller must specifically opt into allowing that mutation when it invokes the function using the & syntax:

doSomething(value: &localValue)

This is the caller taking responsibility for the fact that the function is allowed to perform a mutation. If it does not want the function performing a mutation it can do the copy dance itself:

var copyValue = localValue
doSomething(value: &copyValue)

That is in stark contrast with reference types, in which when you pass a reference to a function you have no control over whether or not that function can perform a mutation.

And second, Swift does not allow you to pass inout values to escaping contexts, so something as simple as this does not compile:

func doSomething(value: inout Int) {
  DispatchQueue.main.async { value += 1 }  // 🛑
}

This too is in stark contrast with reference types in which it is completely fine to pass them around however you want and mutate them at any point.

So it really is semantically equivalent to substitute any function of the form (S, …) -> S with a function of the form (inout S, …) -> Void. There are no unintended side effects and there is no way for the mutation to spread further than you explicitly allow.

And for one last silly but illustrative example, we would never think twice about performing a local mutation like this in code:

var count: Int = …
…
count += 1

But that really is no different than passing count to an inout function that increments:

var count: Int = …
…
increment(&count)

The increment function isn't any scarier or more dangerous to use than += just because it uses inout. And for what it's worth, even += uses inout under the hood.

[maksimn]

@mbrandonw, thank you for the answer.

[lo1tuma]

Thanks everyone for the answers so far. And sorry that I’m so slow with responding 🙈.

To summarize what I understood so far: mutations in swift are safe and explicitly visible by the caller and callee.

In comparison to JavaScript I don’t think there is a huge difference regarding safe mutations. One big disadvantage in JavaScript is that by default mutations are always possible unless someone explicitly freezes the value, so mutations are implicitly always allowed. I think it can be compared to Swift when inout would be an implicit default behavior.

That’s being said, I think my initial question hasn’t really been answered. Even if mutations in Swift are safe. What was the intent of using this approach for updating the state? Was it just a design decision? Or was there some kind of performance implication when using immutable data structures instead of mutation?

Since I’m a functional programming enthusiast a mutation feels always wrong and would be the last option I would consider to solve a problem (that also includes code like count += 1). A mutation is still a side-effect, even if it is intentional. I’m also worried about the single responsibility principle. A reducer function is currently responsible for two things: mutating the state and running effects. I think it would be better to treat a state mutation also as an effect.

[mbrandonw]

Hi @lo1tuma, I have some responses below:

In comparison to JavaScript I don’t think there is a huge difference regarding safe mutations. One big disadvantage in JavaScript is that by default mutations are always possible unless someone explicitly freezes the value, so mutations are implicitly always allowed. I think it can be compared to Swift when inout would be an implicit default behavior.

Mutable-by-default is not the only problem with JS objects, and in fact it's kinda the least pernicious. The real problem with JS objects is that they are reference types, and so that when you do mutate them, that mutation is visible to everyone holding a reference and you can never know who mutated your object or when it was mutated.

Take this snippet as an example:

const obj = {message: "Hello"}

setTimeout(() => { alert(obj.message) }, 10000)

obj.message = "Goodbye"

If you read this code from top-to-bottom you would hope that the alert displays "Hello", but in reality it shows "Goodbye". The mutation made at the end of the snippet is allowed to affect a completely different part of the code that was executed 10 seconds later. And this is assuming that obj wasn't mutated by some other part of the application during that 10 seconds, which is totally possible but we have no way of knowing.

And it's for this reason that people tend to completely disallow mutation in JS and instead require the use of frozen data types, which means you must construct all new values from scratch anytime you want to make a change, no matter how small.

But consider the following code that uses inout in Swift:

func greet(message: inout String) {
  DispatchQueue.main.asyncAfter(deadline: .now() + 10) {
    print(message)  // 🛑 Escaping closure captures 'inout' parameter 'message'
  }
  message = "Goodbye"
}

This simply does not compile. You are not allowed to pass inout values to closures that can be executed at a later time.

This shows that the Swift compiler has our back whenever we try to perform mutations that can be observed from a far distance. The only kinds of value-type mutations that are allowed are restricted to very local scopes and only when we use explicit sigils (var, &, inout).

And this is the main reason that it is not necessary to pass the state as an immutable value. That would force us to construct a whole new value from scratch even if we need to change one tiny thing on the inside of the state.

That’s being said, I think my initial question hasn’t really been answered. Even if mutations in Swift are safe. What was the intent of using this approach for updating the state? Was it just a design decision? Or was there some kind of performance implication when using immutable data structures instead of mutation?

There are two sides to the intent, one of which I did explain. It is a massive improvement of ergonomics. Why write every reducer in this form:

func reduce(state: State, action: Action) -> (State, Effect) {
  // 1️⃣ Make a copy
  var state = state
  switch action {
  case .buttonTapped:
    // 2️⃣ Perform mutation
    state.count += 1
    // 3️⃣ Return new state
    return (state, …)
  }
}

…when there is no tangible benefit to the state argument being non-inout? In fact, making a copy and then mutating is just an adhoc recreation of what the language gives you for free with inout.

Even worse, if you decide to make all the fields in your state lets instead of vars you will have to do something more like this:

func reduce(state: State, action: Action) -> (State, Effect) {
  switch action {
  case .buttonTapped:
    // 1️⃣ Construct a whole new state
    let result = State(
      count: state.count + 1,
      // 2️⃣ Provide every field that did not change
    )
    // 3️⃣ Return new state
    return (state, …)
  }
}

Why do all of that when you can just do:

func reduce(state: inout State, action: Action) -> Effect {
  switch action {
  case .buttonTapped:
    // 1️⃣ Make mutation. No more steps.
    state.count += 1
    return …
  }
}

No need to perfom an explicit copy and no need to complicate the return type with a tuple or custom data type.

The ergnomics of inout is by far the biggest reason to use it, but the other reason is for a possible performance benefit. It is not guaranteed, but sometimes it is possible for the Swift compiler to optimize away copies of value types and perform in-place mutations. And hopefully in the future this can be strengthened to guarantees once Swift has non-copyable types.

Since I’m a functional programming enthusiast a mutation feels always wrong and would be the last option I would consider to solve a problem (that also includes code like count += 1).

As I hope it is clear from everything discussed in this thread, not all mutations are created equal. There are mutations that are uncontrolled and expansive, and then there are mutations that are local to a lexical scope.

Even the most ardent practioner of functional programming should not have any problems with local mutation. In fact, local mutation is often considered a practical way to simplify local logic in a function and improve local performance in pure functional languages. Haskell even has data types specifically for dealing with local mutation (ST, IORef, MVar, TVar and more).

A mutation is still a side-effect, even if it is intentional.

Respectfully, this just is not correct when it comes to Swift and value types. A local mutation is not a side effect. We would never say the following function has a side-effect:

func increment(value: Int) -> Int {
  var result = value
  result += 1
  return result
}

…because the outside world cannot detect that anything changed. It is all local to the function.

And further, the same is true of inout specifically because the only code that can see the mutation is the direct parent scope, and that parent had to make the explicit choice to allow mutation via the & sigil.

I’m also worried about the single responsibility principle. A reducer function is currently responsible for two things: mutating the state and running effects. I think it would be better to treat a state mutation also as an effect.

There is no universal definition of "single responsibility". It's quite nebulous and everyone has their own interpretation. We choose to define the responsibility of reducers as doing whatever is needed for a feature in an app. There is almost never a feature that only needs to do state changes or only needs side effects. Almost every feature needs to do both, and so needlessly separating those concepts only leads to code that is more difficult to understand, harder to maintain, and hurts the ergonomics of the kinds of tools we can offer at the library level.

[lo1tuma]

Thanks again for your detailed reply 🙂.

The real problem with JS objects is that they are reference types, and so that when you do mutate them, that mutation is visible to everyone holding a reference and you can never know who mutated your object or when it was mutated

Yes, that is definitely a problem. And this is also one of the reasons to avoid mutating data structures. I still think swift code using inout and & could be confusing in the same way, at least in a synchronous context. So let’s say you pass down a value type via & to a function and that function passes the value to another function using & and so on. One or multiple of those functions could mutate the value and it might not be easy to figure out which change came from which function or even if they changed the same parts of the value.
Not allowing to mutate inout parameters in an escaped closure is definitely a good idea and necessary in swift to avoid race conditions and/or deadlocks.

In fact, making a copy and then mutating is just an adhoc recreation of what the language gives you for free with inout.

I agree. That also wouldn’t really change anything, since the state is still handled as a mutable data structure.

Even worse, if you decide to make all the fields in your state lets instead of vars you will have to do something more like this:

My initial idea would be to use lenses in order to apply the changes to the state value in an immutable way. Although I have no idea if there are any good lenses libraries in Swift available.
The biggest advantage I see here, is that using immutable data structures and pure functions improves reusability and composability. For example a small function could be created that increases the count property for the given lens and the given state, this function could then be reused in several reducers. I have something like this in mind

func reduce(state: State, action: Action) -> Effect {
  switch action {
  case .buttonTapped:
    return pipe(
        increaseCounter(state),
        trackUIAction,
        // ...
    )
  }
}

A local mutation is not a side effect.

You are right. Sorry, I was only referring to non-local mutations.

And further, the same is true of inout specifically because the only code that can see the mutation is the direct parent scope, and that parent had to make the explicit choice to allow mutation via the & sigil.

I guess this depends. When the parent scope received the value as an inout parameter as well, then you have several layers involved.

We choose to define the responsibility of reducers as doing whatever is needed for a feature in an app.

I think that definition is fine for the scope of a reducer. But it becomes really hard to extract some parts from a reducer to a small module or function, not interfering with the responsibility of the reducer.

[tgrapperon]

Hey @lo1tuma! While a few of the points above can be debated, the key argument that makes all of this always sound in the context of TCA is that the inout State that the reducer receives is not univocally mutating the app's state. It is mostly the case de-facto internally because that's convenient and performant in our case, but we would be totally free to discard the modifications you perform in the reducer by simply not writing the state back to the store. It'd mean that you'd receive a state, perform whatever mutation you want on it, and it wouldn't affect the app state in any way if we would like to be this way.

As Brandon says, the & sigil is a clear signal that the value you pass can be modified, and it's always the responsibility of the caller to make sure that this is not problematic in a given context. In the context of reducers, we definitely want reducers to potentially mutate the state we pass to them. We could rewrite all reducers' boundaries using functions like (State, Action) -> (State, Effect<Action>) instead, and it wouldn't change anything in terms of safety or testability. It would only make the app slightly less performant and much more annoying to write for the user.
I think we can even demonstrate it by implementing a sub-protocol of Reducer that would have this kind of reduce signature:

public protocol NonInoutStateReducer: Reducer {
  func reduce(state: State, action: Action) -> (State, Effect<Action>)
}

extension NonInoutStateReducer {
  public func reduce(into state: inout State, action: Action) -> Effect<Action> {
    let (_state, effect) = self.reduce(state: state, action: action)
    state = _state
    return effect
  }
}

This thing would directly work without having to make a single change to the library. It wouldn't make it more or less safer, reusable or composable though.

[Alex293]

On a side note a Lens is juste a pair of getter and setter unapplied and a writable key path is an implementation of a Lens so TCA is based on the use of lens also CasePaths are Prisms. IIRC there are episodes discussing this.

[mbrandonw]

Hi @lo1tuma,

I still think swift code using inout and & could be confusing in the same way, at least in a synchronous context. So let’s say you pass down a value type via & to a function and that function passes the value to another function using & and so on. One or multiple of those functions could mutate the value and it might not be easy to figure out which change came from which function or even if they changed the same parts of the value.

Passing an inout value through multiple layers is not a problem at all, specifically because of the locality property I explained above. When you invoke a function like f(&x) you don't need to care if f also called a g and an h that also mutated x. There's really nothing of value in knowing that information because of the local nature of the mutation.

This local property is in fact one of the main benefits to pure functional languages. As long as you know that some operation is well-behaved in a local context you can be very sure it will behave correctly when composed into something much more complex without fretting about all the details. And even though Swift is not a functional language by any stretch of the imagination, inout is a well-behaved, local construct.

My initial idea would be to use lenses in order to apply the changes to the state value in an immutable way. Although I have no idea if there are any good lenses libraries in Swift available.

Swift is perhaps the only mainstream language in existence that has first class support for lenses (called key paths), but also they wouldn't buy you much here. You would have to contort yourself in weird ways to leverage key paths when the equivalent local mutation would be simpler and more performant.

The biggest advantage I see here, is that using immutable data structures and pure functions improves reusability and composability. For example a small function could be created that increases the count property for the given lens and the given state, this function could then be reused in several reducers. I have something like this in mind

func reduce(state: State, action: Action) -> Effect {
  switch action {
  case .buttonTapped:
    return pipe(
        increaseCounter(state),
        trackUIAction,
        // ...
    )
  }
}

The equivalent of this code in a value type mutation world is the following:

struct State {
  var count: Int 
  mutating func increment() {
    self.count += 1
  }
}

func reduce(into state: inout State, action: Action) -> Effect {
  switch action {
  case .buttonTapped:
    state.increment()
    return trackAnalytics
  }
}

Instead of having a free function increaseCounter you have a mutating function on the struct increment, and it can be used anywhere. And because of the nature of value types and value mutation, this is not a dangerous kind of mutation. It is 100% equivalent to the code you wrote. Both styles have the exact same level of safety, reusability, composability, etc., but the mutation style is simpler to work with and more performant.

I guess this depends. When the parent scope received the value as an inout parameter as well, then you have several layers involved.

This really isn't true though. The main reason to want tools that have strong local reasoning is specifically so that you can use them in complex, multi-layered ways without having to worry about the details. This is one of the big powers of functional languages, and even though Swift is not functional at all, it does come with tools that have strong local reasoning, inout being one of them.

I think that definition is fine for the scope of a reducer. But it becomes really hard to extract some parts from a reducer to a small module or function, not interfering with the responsibility of the reducer.

This is also not true in practice. We have built many demos and case studies in this repo, and real world applications that modularize features and create many bits of functionality that can be extracted and shared across many reducers. There is no problem at all with doing that using the (inout S, A) -> Effect<A> style of reducer, but there are lots of benefits.

---

I think what would be really helpful is if you could write some compiling Swift code that demonstrates the problems you are seeing. Right now all of our discussions have been a little nebulous. Seeing some concrete, compiling code could help us understand your concerns.