Strange behavior of @DependencyClient

[ghost]

I previously had this struct definition for a dependency:

public struct ImportHandlerClient {
	public var importRoot: (URL) async throws -> TRoot
	public var seedRoot: (TRoot) async throws -> Void
	public var fetchURL: () -> URL
}

I now added @DependencyClient in front to the struct. I expected it to simply compile, but I got this error message:

Default value required for non-throwing closure 'fetchURL'
Insert '= { <#URL#> }'

This is somehow strange: why Is this error thrown at all? And why only for the third of these declarations, and not for the other two as well?

[mbrandonw]

Hi @innoreq, the compiler diagnostic is trying to describe the situation. Any endpoint in your client that is non-throwing must have a default value. And the fix-it tries to help:

Insert '= { <#URL#> }'

The reason this is needed is because one of the main uses of @DependencyClient is to generate a default initializer for your client that simply throws an error / triggers an XCTest failure in each endpoint. That's what allows you to simply do ImportHandlerClient() to construct a client, which is appropriate to use for your testValue. We discuss this a bit in the docs.

How could the compiler diagnostic have been improved to make this clearer?

[ghost]

Thanks a lot. I already followed the compiler instructions, so that it was fixed, but it was not clear to me why this behavior occurred. Thanks for the clarification!

[ghost]

How could the compiler diagnostic have been improved to make this clearer?
The message tells the technical reason and the fix, so it's actually ok. However, the rationale behind would be useful in that situation.

[mbrandonw]

Hi @innoreq, we'll take a look at improving this. Maybe we can just link to some docs in that diagnostic.

[andriyslyusar]

In our project we use Client.Interface as close as possible to Protocol, to only give overview of public methods. Now using @DependencyClient we are forced to mix-match the dependency framework logic. Do you think of any ways we can avoid it and automatically generate XCTestDynamicOverlay.unimplemented("...") for none-throwing closures?

[mbrandonw]

Hi @andriyslyusar, can you please start a new discussion and explain exactly what your issue is and share some code that demonstrates the problem you are having.