TCA built-in dependencies do not currently support the new @Dependency(XXX.self) var xxx paradigm

[wltrup]

Description

In view of #172, it appears as though some (or perhaps all - I didn't check) of the TCA built-in dependencies do not support the new paradigm. I was updating one of my projects, which uses the Date dependency, and I noted that

@Dependency(Date.self) var date

results in the compiler error

Initializer 'init(_:file:fileID:line:)' requires that 'Date' conform to 'TestDependencyKey'

Now, this isn't a big deal for my project since the old

@Dependency(\.date) var date

still works but I thought I'd let you know.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

Dependencies version information

1.2.0

Destination operating system

iOS 15+

Xcode version information

Version 15.3 beta 3 (15E5194e)

Swift Compiler version information

swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)

[mbrandonw]

Hi @wltrup, you cannot use @Dependency(Date.self) even in swift-dependencies because, as the error points out, we did not conform Date to TestDependencyKey. Instead we decided to create a private key conformance, which means the only way to access the dependency is via @Dependency(\.date). We did this because we don't think it's appropriate to conform such a foundational type as Date to our protocols, thus littering it with liveValue, previewValue and testValue for everyone.

The @Dependency(Client.self) style is mostly geared towards dependencies you ship in your own projects rather than dependencies you ship as apart of a library. For library dependencies it's probably best to stick with the key path syntax.

Since this isn't an issue with the library I am going to convert this to a discussion.

[wltrup]

Hi Brandon.

We did this because we don't think it's appropriate to conform such a foundational type as Date to our protocols, thus littering it with liveValue, previewValue and testValue for everyone.

Ah, that makes perfect sense. Thanks.