Need help creating a protocol for state types that must have a destination property

[ghost]

Hello :)

I'm trying to create a protocol for reducer state types that participate in navigation by requiring them to have a

@PresentationState public var destination: Destination.State?

property but the compiler doesn't let property wrappers in protocol requirements so this isn't valid Swift code:

public protocol ScenePresenterState: Equatable {
   associatedtype DestinationState: RawRepresentable
   @PresentationState var destination: DestinationState? { get set }
}

I thought this might work, instead,

public protocol ScenePresenterState: Equatable {
   associatedtype DestinationState: RawRepresentable
   var destination: PresentationState<DestinationState>? { get set }
}

but the compiler still complains that my states don't conform to the ScenePresenterState protocol. I was under the impression that property wrappers make it look like the property being wrapped is of the type we care about but, under the hood, it's actually of the wrapper type, so why doesn't the latter work? And if the latter doesn't work, can someone offer a solution?

Many thanks in advance.

[Alex293]

Only phone but try adding a _ before the protocol field so it matches the backing field

[ghost]

Hi @Alex293, thanks for replying. If you mean this,

public protocol ScenePresenterState: Equatable {
   associatedtype DestinationState: RawRepresentable
   var _destination: PresentationState<DestinationState>? { get set }
}

the compiler no longer complains that it's not valid code, so that's great, but it still complains that the state doesn't conform to the protocol, even after I explicitly set the typealias (which is what the fix-it adds), as in

public struct LoginScene: ReducerProtocol {
   public struct State: ScenePresenterState {
      public typealias DestinationState = Destination.State
      @PresentationState public var destination: Destination.State?
   }
}

[ghost]

It's also not clear to me where the ? should go, ie,

public protocol ScenePresenterState: Equatable {
   associatedtype DestinationState: RawRepresentable
   var _destination: PresentationState<DestinationState>? { get set }
}

or

public protocol ScenePresenterState: Equatable {
   associatedtype DestinationState: RawRepresentable
   var _destination: PresentationState<DestinationState?> { get set }
}

I tried both but neither worked.

[pyrtsa]

I'm trying to create a protocol for reducer state types that participate in navigation by requiring them to have a

@PresentationState public var destination: Destination.State?

property but the compiler doesn't let property wrappers in protocol requirements

@wtruppel Unfortunately i think it isn't possible to model that design as a protocol requirement. The main issues being:

• the wrapped property would become a computed property of signature var destination: DestinationState? { get set } – this is the only part that you could require as part of the protocol interface, if it wasn't for the other issues below!
• the property wrapper would become private var _destination: PresentationState<DestinationState?> – that stored property couldn't be part of the protocol interface because it's private and thus less visible than the enclosing type (although maybe you wouldn't need the underscored property in the protocol for the same reasons!)
• there's also the projected value at var $destination: PresentationState<DestinationState?> { get set }, but unfortunately dollar-prefixed identifiers aren't currently allowed even in protocol interfaces; see https://forums.swift.org/t/property-wrapper-requirements-in-protocols/33953/43

[ghost]

Hi @pyrtsa , thank you for your response.

That's unfortunate, because I have some common behaviour that I could move to a protocol extension if I could write the protocol I wanted. As it is, I'll have quite a bit of repeated code.

[Nevwild]

Have you considered implementing a protocol witness, and adding it as a dependency?Best,Nevill WilderOn Jun 13, 2023, at 01:56, Wagner ***@***.***> wrote: Hi @pyrtsa , thank you for your response. That's unfortunate, because I have some common behaviour that I could move to a protocol extension if I could write the protocol I wanted. As it is, I'll have quite a bit of repeated code. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ghost]

Hi @Nevwild, thanks for answering. Could you elaborate on your suggestion? I know what protocol witnesses are, more or less, but it's not something I know well enough to understand right away what you are proposing. Thanks!

[lukeredpath]

Could you elaborate on what you’re trying to do? As above I don’t think you can model this as a protocol. If you’re trying to reduce some boilerplate, maybe macros will help in the near future.

[ghost]

Hi @lukeredpath. Thanks for replying to my question.

As I indicated, I'm trying to create a protocol for certain reducer state types (those that participate in navigation) because those types have code (not just boilerplate) that I could move into a protocol extension so that I wouldn't have to repeat it in every type. Macros would definitely help but we can't make use of them just yet. It's not a huge deal, just more code to write and maintain at the moment.

[Nevwild]

Hey Wagner, I was noticing that you were saving destination state in your protocol. I’m curious what the intent is behind that    Perhaps you’re trying to perform some mutations on the destinations state before it is created? Are you sure you want to directly edit that state outside the scope of the destination reducer? I ask these questions because there are other patterns in the TCA that should allow you to interact with child state without exposing it to other reducers.Otherwise, I would advise that you go and look at the series of pointfree episodes on protocol witnesses, and see if you can do everything you’re trying to do with your protocol using a concrete witness typeBest,Nevill WilderOn Jun 14, 2023, at 01:49, Wagner ***@***.***> wrote: Hi @lukeredpath. Thanks for replying to my question. As I indicated, I'm trying to create a protocol for certain reducer state types (those that participate in navigation) because those types have code (not just boilerplate) that I could move into a protocol extension so that I wouldn't have to repeat it in every type. Macros would definitely help but we can't make use of them just yet. It's not a huge deal, just more code to write and maintain at the moment. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[ghost]

Hi @Nevwild. No, actually the protocol I have in mind only needs to read the destination. The { get set } was a mistake. I have watched the episodes on protocol witnesses (a long time ago) and will revisit them but it would save me a great deal of time if you could briefly describe why you think protocol witnesses might help in this scenario. Thanks!