Should `Effect.init(value:)` take an `@autoclosure`?

Related Projects Swift Composable Architecture
1

I think Effect.init(value:) should evaluate value lazily at the time its subscribed, which can be later-on if theres multiple effects, so it can actually produce a different result.

Afaik this can be done with @autoclosure @escaping without loosing ergonomics.

Similar with Effect.init(error:).

I can think more about this, provide code or PR if theres support. First I wanna see if Im not missing some obvious counterargument.

2

We discussed this before open sourcing but ultimately decided to avoid laziness for this API, since Effect.init(value:) should really only be invoked with a pure value, but we're definitely open to revisit with some discussion! Maybe an example of code that would benefit from laziness would help?

3

Does an extra stupid example count? :sweat_smile:

return .merge([
  .init(value: environment.now()).map(Action.secondDate),
  .init(value: environment.now()).map(Action.firstDate),
].reversed())

//--------
assert(firstDate < secondDate)

I hope this nicely surfaces the argument here:

  • without laziness, theres needless impurity
    vs.
  • with @autoclosure laziness, theres needless hidden complexity

I was gonna let this go, but now I found myself using .catching on something non-throwing just to avoid this dilemma :grinning:. So I guess Im still on team Pure, anyone care to join?

I dont wanna fabricate semi-real examples, so I'll come back once I have something real.