Replace Send struct with a nonescaping closure?

[dankinsoid]

Now when using .run { send in ... } it's possible to use send in escaping closures, smth like

.run { send in
    someFuncWithCompletion { result in 
         Task {
            await send(.action(result))
         }
    }
}

It's wrong to do so, but It's possible and what's more, it's confusing: some developers may get the feeling that run is for such cases and take run as an analogue of withCheckedContinuation, Observable.create etc.
But if we replace the Send with @MainActor @Sendable (Action) -> Void, then such an incorrect use of thesend will become impossible.

[mbrandonw]

Hi @dankinsoid, it would be great if this were possible, but unfortunately I don't see how.

The reason we bundle the closure up in a Send type is for ergonomics. This allows one to send actions like this send(.action), as well as with animation send(.action, animation: .default). Those ergonomics just aren't possible with a bare closure since you can't provide a default to a closure argument, and so we'd have to drop the animation argument and force people to do this:

await MainActor.run {
  withAnimation {
    send(.action)
  }
}

But, the downside to wrapping the closure in the Send type is that it forces the closure to be escaping even though we never use it as such. The only times we construct Send is to pass to the effect operation and then we immediately discard it. We never actually use it in an escaping manner.

Swift does have a tool to help with the impedance mismatch between escaping and non-escaping, and it's called withoutActuallyEscaping, but I don't think it helps us here. Perhaps some of the new move only / @noncopyable tools coming to Swift will be able to help here.

So, unless someone has an idea to keep the ergonomics of send while improving its compile-time safety I'm afraid we might need to keep the static quo. We did at least recently add a runtime warning if send is used in an incorrect way. See #1900. Of course a compile-time error would be much better, but at least it's something.

[dankinsoid]

@mbrandonw I see, thank you.
To define animation in reducers instead of views, is it a common practice? It seems strange to me
Maybe it's possible to find some workarounds

.run { send in
   await send(.action)
}
.animation(.default)

.run { send in
   await send(withAnimation { .action }) // I've seen similar code and it works, I suspect this should work too
}

[mbrandonw]

There are two types of animation in SwiftUI: implicit and explicit. Implicit, which is done with the .animation view modifier, is a blunt but powerful tool. It simply tells SwiftUI to animate everything in a particular branch of the view tree. You can somewhat focus its energy by using the value argument, but still it's quite blunt. For example, you can't decide which kind of animation curve to use based on how state changed.

Explicit animations allow you to make a specific mutation to state and tell SwiftUI to animate the view from those state changes in a particular way. This is a hyper focused way of doing animations, and it's what send(_:animation:) allows for. For example, suppose you wanted to send timer ticks into the system with no animation, and then one final action with animation. That is possible:

return .run { send in
  var tickCount = 0
  for await _ in self.clock.timer(interval: .seconds(1)) where tickCount <= 10 {
    defer { tickCount += 1 }
    await send(.timerTick) // no animation
  }
  await send(.timerFinished, animation: .default) // animation
}

This is something we take advantage of a lot in our isowords game, where we construct one big effect that sends various actions with different animation curves and durations. So, we definitely don't want to lose it.

The first code snippet you posted is possible today:

.run { send in
  await send(.action)
}
.animation(.default)

The Effect type has an animation method that animates every emission. However, that is still pretty blunt because you don't get to decide which action is sent with which animation.

The last code snippet you posted does not work:

.run { send in
  await send(withAnimation { .action }) 
}

withAnimation only works by seeing the state of things before and after the closure is executed, and nothing actually changes inside the closure in the above. It's only when the action is actually sent is the state changed in the feature. That is why this is necessary:

await MainActor.run {
  withAnimation {
    send(.action)
  }
}

So, we really do want to support animation in send, but I'm not sure how to do it with good ergonomics and so that it isn't see as "escaping" to the Swift compiler.

[dankinsoid]

@mbrandonw Thank you for a such detailed answer!
What about this syntax?

.run { send in
  await sendWithAnimation {
      send(.action)
  }
}

https://github.com/dankinsoid/TCA-nonescaping-send

[mbrandonw]

Hi @dankinsoid, yes that is technically possible, and it would also work if withAnimation in SwiftUI was annotated as @MainActor:

await withAnimation { send(.action) }

If SwiftUI made that change we might consider dropping the Send type, but otherwise we don't think we should be shipping new APIs to make up for that oversight.

We do think that the new ownership stuff coming to Swift may help with this, so we are going to wait a bit longer before making any changes.

[dankinsoid]

I have a notice about @noncopyable
As I understand it, it will be impossible to pass the Send object to an escaping closure, but it will be possible to pass the method itself

.run { send in 
   let _send = send.callAsFunction
   someMethodWithCompletion {
      _send(action)
   }
}