Composing CaseKeyPaths and KeyPaths

[davdroman]

Thanks to the new macro implementation, CaseKeyPaths are naturally composable via dot syntax just as KeyPaths, but when trying to compose CaseKeyPaths with normal KeyPaths unfortunately the compiler errors out.

@CasePathable
enum PaymentType {
	case creditCard(CreditCard)
}

struct CreditCard {
	var number: String
	// ...
}

\PaymentType.Cases.creditCard.number // 🛑 Generic parameter 'AppendedValue' could not be inferred
                                     // 🛑 Subscript 'subscript(dynamicMember:)' requires that 'CreditCard' conform to 'CasePathable'

Is this a technical limitation that can't be circumvented, or something pending to be implemented in the future perhaps?

[stephencelis]

@davdroman Just curious, what is your expectation with the above path and how would you like it to be used?

[davdroman]

Oh, sorry! I genuinely thought I was opening a discussion instead of an issue. My bad.

My expectation for that path would be for me to be able to extract the String value as an optional. For example:

let paymentType = PaymentType.creditCard(CreditCard(number: "12345"))
paymentType[case: \.creditCard.number] // Optional<String>("12345")

Similarly, for setting values if the enum case matches:

var paymentType = PaymentType.creditCard(CreditCard(number: "12345"))
paymentType[case: \.creditCard.number] = "56789" // ✅ because case matches, otherwise it'd be a no-op

Does this make sense?

[davdroman]

I guess I should give a bit more context on why I want this. While using TCA, I was trying to Scope a reducer action down to a specific property in the action enum case payload, but I found I wasn't able to do it because I can't compose CaseKeyPaths with KeyPaths.

[stephencelis]

@davdroman Both of the examples above are maybe too concrete to get at the meat of the issue, so I'd be curious if you have a sketch of how you were trying to use Scope.

One thing to note is that for access, if you use @dynamicMemberLookup you can get a key path to the underlying thing:

 let paymentType = PaymentType.creditCard(CreditCard(number: "12345"))
-paymentType[case: \.creditCard.number]      // 🛑
+paymentType[keyPath: \.creditCard?.number]  // Optional<String>("12345")

For setting into the thing it's more complicated. Remember that case paths can unconditionally embed. So say that theoretically \PaymentType.Cases.creditCard.number returned a CaseKeyPath<PaymentType, String>. The embed for sure cannot work if CreditCard contains other fields:

let paymentTypePath = \PaymentType.Cases.creditCard.number
paymentTypePath("12345")  // ⁉️

So I guess the main question is, what kinds of generic algorithms are you trying to write? And what are some concrete examples of using them?

[davdroman]

Nice tip on @dynamicMemberLookup, that's clever.

I can see why CaseKeyPath<PaymentType, String> isn't really possible. It doesn't even make sense at all as a type, really.

I don't know, I'm quite tired at the moment so I might need to revisit this at some other time when I'm more fresh and get back to you with a proper example. Nonetheless thanks for your help!

[stephencelis]

Please do! For what it's worth there is a composable thing here, but requires introducing a kind of path in between case paths and key paths to degrade to, which contains a non-optional setter and optional getter. We've called this an OptionalPath in the past:

struct OptionalPath<Root, Value> {
  let get: (Root) -> Value?
  let set: (inout Root, Value) -> Void
}

While we have explored a way of making this work, we haven't wanted to commit to introducing the API surface area till there are some significantly motivating use cases. Almost all of the uses of OptionalPath we've had in the past were due to not quite modeling our domains properly.

[danthorpe]

I stumbled upon this recently, as I found myself also trying to make use of a generic WriteableKeyPath, where the some elements of the path included enums.

The use case I have, is that in a hyper modular project, using TCA, imagine we have a child feature module, which is composed by two different ancestor modules. When we write the tests for the ancestor feature, we want to strike a balance between exhaustive testing, but also readable and maintainable code. To this end, it's useful to provide Test Helper modules alongside the child feature module which the test targets of dependent modules can make use of.

These test modules might expose functions like

public func assertChildFeature<State: Equatable, Action: Equatable>(
  in store: TestStore<State, Action>, 
  state: WritableKeyPath<State, ChildFeature.State?>,
  action: CaseKeyPath<Action, ChildFeature.Action>,
  behaviour: String,
  expectedResult: TaskResult<Bar>
) async 

We need the state and action paths - because the child feature does not know how it has been integrated into any ancestor. And TestStore scoping has been deprecated.

But, anyway, it seems that if the state is composed using any enum state - then this cannot be achieved, because - as you point out, we cannot write the complete associated type of an enum if the key path is further refined.

I think, the only options for a mixed case like this, is to provide a function which returns an inout assertion closure. So the test helper can execute this function, and provide the assertion.