Support nested enum reducer (#2813)

[sk409]

This adds support for nested enum reducers.
#2813 for more information.

[stephencelis]

@sk409 Thanks for the discussion and motivation. I think we're down to support this, but maybe in a way that doesn't introduce a new macro like @ReducerCaseStatic.

Instead, what if we used Feature.Body to denote a static reducer?

-@ReducerCaseStatic
-case sheet(Sheet)
+case sheet(Sheet.Body)

That would match explicit use in the reducer:

.ifLet(\.$sheet, action: \.sheet) {
  Sheet.body
}

What do you think?

[sk409]

@stephencelis

Instead, what if we used Feature.Body to denote a static reducer?

I agree with the policy of not introducing new macros if possible.
I tried using Body in the example below, but Body was Never because the ReducerBuilder's _Sequence defines reduce.
This results in an error like the attached screenshot.

extension FeatureA {
    @Reducer(state: .equatable)
    enum Destination {
        case modal(Modal.Body)
    }
}

extension FeatureA {
    @Reducer(state: .equatable)
    enum Modal {
        case featureB(FeatureB)
        case featureC(FeatureC)
        case featureD(FeatureD)
    }
}

[stephencelis]

@sk409 Sorry if I wasn't clear, or maybe I'm misunderstanding you, but my suggestion was for the macro to see Modal.Body and then use that .Body to insert different code in the body, like:

 ComposableArchitecture.Scope(
   state: \Self.State.Cases.modal, action: \Self.Action.Cases.modal
 ) {
-  Modal()
+  Modal.body
 }

Are you interested in making those changes to this PR?

[sk409]

@stephencelis

my suggestion was for the macro to see Modal.Body and then use that .Body to insert different code in the body, like:

Thank you for confirmation.
I think it's simple and clear because .Body and .body correspond.
I have implemented it, so please check if there are any discrepancies in recognition.
481bfc7
The body of the nested enum reducer has a detailed type and I needed to erase the type, so I implemented it as follows.

 ComposableArchitecture.Scope(
   state: \Self.State.Cases.modal, action: \Self.Action.Cases.modal
 ) {
  ComposableArchitecture.Reduce(Modal.body.reduce)
 }

[stephencelis]

@sk409 Sorry for the extra back and forth, but it's taken us awhile to process the problem and potential solutions. We think we have an idea that minimizes magic and also enhances the reducer macro for even more general cases. Instead of detecting .Body and performing some magic, what if we used the optional "initializer" of the case as the scoped default? For example:

case sheet(Sheet.Body = Sheet.body)  // No magic, just use `Sheet.body` in the scope

This also would allow folks to customize struct reducers that take some static configuration, which is currently impossible:

case child(Child = Child(context: .sheet))

Thoughts? Are you up for making this final change? We promise no more back-and-forth 😄

If you don't have the time, though, we can also attempt to tackle soon.

[sk409]

@stephencelis

what if we used the optional "initializer" of the case as the scoped default? For example:

I think it's good because it can be used in various cases.
I implemented it.
I added the following test after implementation, but a compilation error occurred because Sheet.Body was Never.

private enum TestEnumReducer_Nested {
  @Reducer
  struct Feature {}
  @Reducer
  enum Destination {
    // Compilation error occurs because Sheet.Body is Never.
    case sheet(Sheet.Body = Sheet.body)
  }
  
  @Reducer
  enum Sheet {
    case feature(Feature)
  }
}

It seems that there will be no compilation error if I change Sheet.Body to Sheet._Body, but why does Sheet.Body become Never?

private enum TestEnumReducer_Nested {
  ....
  @Reducer
  enum Destination {
    // No compilation error occurs because Sheet._Body is not Never.
    case sheet(Sheet._Body = Sheet.body)
  }
  ...
}

[stephencelis]

@sk409 That's a bummer :( This looks like it might be a macro bug/issue. We'll chat about it and investigate a bit further.

[stephencelis]

This appears to be working with the changes from #3023, so will merge when #3023 is merged, thanks for making all the changes!