Using Self as default associated type of DependencyKey.Value

[pteasima]

Discussion to go alongside my draft PR #1395

#1395 (comment)

@stephencelis @mbrandonw in case you end up rejecting this, would you mind elaborating why your sample code favors separate enums for defining the DependencyKey conformance? I like that its possible to do that, but it wouldn't be my first choice for a best practice.

[mbrandonw]

Hey @pteasima, this makes a lot of sense to me. I'm gonna chat about it with @stephencelis and we'll get back to you!

[tgrapperon]

This change invites to define overloads when the DependencyKey.Value is Self:
https://github.com/pointfreeco/swift-composable-architecture/compare/protocol-beta...tgrapperon:swift-composable-architecture:protocol-beta-self-dependency-key?expand=1
It would allow to bypass the definition of the computed property in DependencyValues, which is almost always 100% boilerplate. But it renders the implementation slightly more complex on TCA's side, and one loses the KeyPath that could maybe serve another purpose in the future, so I don't know what to think about it at the end.

[pteasima]

I guess what I was trying to say below is: Im not opossed to adding this extra sugar if folks feel the pretty syntax is worth it, but I don't see a technical reason to ditch KeyPaths internally. Very similar sugar can be purely additive, without introducing a new type, implemented using the subscript trick internally, as so:

fileprivate extension DependencyValues {
  subscript<Key: DependencyKey>(key path: KeyPath<Key, Key>) -> Key.Value {
    get {
      self[Key.self]
    }
    set {
      self[Key.self] = newValue
    }
  }
}

public extension Dependency {
  //e.g. `@Dependency(API.self) var api`
  init<Key: DependencyKey>(_ key: Key.Type) where Key.Value == Value {
    self.init(\.[key: \Key.self])
  }
}

public extension ReducerProtocol {
  //e.g. `.dependency(API.self, .mock)`
  func dependency<Key: DependencyKey>(_ key: Key.Type, _ value: Key.Value) -> _DependencyKeyWritingReducer<Self> {
    self.dependency(\.[key: \Key.self], value)
  }
}

In my SwiftUI codebases I've decided to use the subscript trick directly, since I didn't feel like managing these two pieces of sugar (+ a few more, like the .transformEnvironment overload). But it is absolutelly an option.

There's a few more things you can do where Self == Self.Value, but result isn't less boilerplaty, just even cleaner syntax, e.g. allowing @Dependency var api: API or .dependency(API.mock).

[tgrapperon]

Ha sorry, I didn't spot the subtlety. This is smart indeed! Are metatypes like Key.self always Sendable? I think they are, but we're in @unchecked regime here, and the current safeguards rely on the apparent impossibility to construct non sendable KeyPaths without warnings (that is KeyPath with non-sendable subscripts). I would like to be sure that we're not passing under the radar with these relatively exotic constructs. It is very likely OK though.

My main concern with the idea is now the loss of autocomplete and discoverability that Brandon mentioned and which is something very nice to have. I don't think that we can bring it back without doing some work equivalent to defining the computed property, or without providing a lesser experience in general.

As an aside and as we're mentioning alternative access to dependencies, we also have enough surface as a third party to define a subscript to ReducerProtocol and completely forgo @Dependency:

@dynamicMemberLookup
public struct EnvironmentDependencies {
  public subscript<Value>(dynamicMember keyPath: KeyPath<DependencyValues, Value>) -> Value {
    DependencyValues.current[keyPath: keyPath]
  }
}

extension ReducerProtocol {
  public var environment: EnvironmentDependencies { .init() }
}

so anywhere in the reducer, one can call self.environment.mainQueue for example. I'm sure many folks won't like it, but maybe this construct can act as a shim and ease the migration from Reducer to ReducerProtocol. As this is very simple and completely implementable by users, it could maybe be only mentioned in the migration guide. This extension should allow to copy/paste the internals of some Reducer's switch into a Reduce without having to update the code once the dependencies are defined.

[pteasima]

The code I posted above compiles, but I haven't tried building it with any strict concurrency settings. Im a bit out of my depth on concurrency for now. I don't see a reason why types wouldn't be Sendable but I also don't know if they are.

I like your idea to use @dynamicMemberLookup to forego defining individual @Dependency vars. But I think the only reasons not to do that are that some people prefer callsite syntax to be api., not environment.api. and some like the explicit listing of dependencies used by this reducer. Somewhat related, I've argued in the past that Swift should allow @dynamicMemberLookup access on self without the leading self., so @dynamicMemberLookup ReducerProtocol can allow the api. syntax. But my tweets on this never gained any traction, and I think an evolution proposal would be shut down on the grounds of being too automagical. But I'd be curious to hear your thoughts on this.

[tgrapperon]

In the case I have in mind, it would not be to replace @Dependency which provides a kind of dependencies checklist for the feature. It's mostly to help folks with reducers built with state, action, environment arguments to transition more swiftly to state, action, by providing environment as a general ReducerProtocol property. So in this case, the fact that we need to have a support for the KeyPath (here environment) is desired. I wouldn't use this approach myself in already protocolized reducers, because I kind of like having all @Dependency gathered in one spot, as it can make required imports clearer. Fortunately, the whole Dependency story looks flexible enough to adapt to many styles.

In any case, you can also install explicitly the most common dependencies in a ReducerProtocol extension without having to go through @dynamicCallable. It could have even been the norm instead of passing through a DependencyValues property and a property wrapper. As these dependencies values are only valid in reduce(:inout State, Action) and body, it would maybe have made more sense, as I'm sure we'll see folks installing and access @Dependency in State at some point. Of course, it would have departed from SwiftUI, and it would also have removed the pseudo containment @Dependency provides, and this property wrapper has furthermore a free projected value that could be useful in the future. But I don't know how it would have worked exactly on the setter's side. I'll toy with the idea at the occasion.

[stephencelis]

@mbrandonw and I discussed and we definitely think this is a cool idea, but we're worried that having multiple ways of accomplishing it in the library might muddy learning/documentation. For now, since these APIs can be added from outside the library quite easily, we're going to hold off, but we're also going to keep this discussion handy for when folks ask about eliminating boilerplate around dependency registration!

Thanks for sharing, @tgrapperon and @pteasima!

[pteasima]

@tgrapperon if you count boilerplate in number of expressions, not number of characters, there's a somewhat ugly trick that might solve your dilemma https://twitter.com/pteasima/status/1570772309866348546?s=21&t=685c149IN0atJ3WF8GTWIw

There are good reasons neither Apple nor pointfreeco have adopted this, but it does avoid several additional overloads and maintains the use of keypaths. This isn't specific to cases where Self = Self.Value, but I think it somewhat obsoletes your argument (your overloads would still avoid the ugly syntax of the subscript trick, but technically wouldn't lead to less boilerplate).

[pteasima]

Also, I think that DependencyOf<AudioPlayer> var audioPlayer syntax can be achieved without AudioPlayer == AudioPlayer.Value

[tgrapperon]

Apple and TCA have very different needs toward Environment/Dependency definitions, and if one can write many SwiftUI apps without defining a custom Environment value, it will likely be the opposite with TCA apps, where having at least a few custom dependencies will be the norm. I'm just saying that the user who will define extension AudioPlayer: DependencyKey that your change invites to do will find annoying to also have to implement the computed property boilerplate, so I was looking at a way to ease their experience. That's also why I suggested restricting to cases where Value == Self.

I think that the real main problem is that one loses the KeyPath and one thus makes dependency handling more complex internally, maybe up to the point of putting us in a corner in the future, so that's why I was looking for potential third party integrations.