Proposal: Support conditionally compiled endpoints in @DependencyClient

[fruitcoder]

Proposal: Support conditionally compiled endpoints in @DependencyClient

I'd like to propose adding support for endpoints declared inside #if / #endif blocks in @DependencyClient.

Motivation

Currently, @DependencyClient only discovers endpoints declared directly in the type body. Endpoints inside conditional compilation blocks are silently ignored, meaning they don't receive the same treatment as unconditional endpoints:

• @DependencyEndpoint isn't applied.
• Generated initializers don't include them.
• The behavior can be surprising, especially when platform-specific APIs are involved.

For example:

@DependencyClient
struct Client {
  var fetch: () -> Void

  #if os(iOS)
  var fetchiOS: () -> Void
  #endif
}

Today, fetchiOS is effectively invisible to the macro.

Proposed approach

The macro would treat declarations inside conditional compilation blocks the same way it treats unconditional members.

During expansion, each #if branch is processed independently and grouped by its compilation condition. These groups are then used during initializer generation.

The generated initializers follow a few rules:

• Unconditional endpoints are included in every applicable initializer.
• Each conditional group receives its own #if-guarded initializer that includes both the unconditional endpoints and the endpoints for that condition.
• Initializers that don't take a conditional endpoint assign it an unimplemented implementation behind the appropriate #if, ensuring Swift's definite initialization rules are satisfied.
• The empty initializer continues to be generated and likewise provides unimplemented implementations for any conditional endpoints.

For the example above, this results in:

// Available everywhere
init(fetch: @escaping () -> Void) {
  self.fetch = fetch

  #if os(iOS)
  self.fetchiOS = /* unimplemented */
  #endif
}

#if os(iOS)
init(fetch: @escaping () -> Void, fetchiOS: @escaping () -> Void) {
  self.fetch = fetch
  self.fetchiOS = fetchiOS
}
#endif

init() {
  #if os(iOS)
  self.fetchiOS = /* unimplemented */
  #endif
}

Keeping behavior consistent

Rather than generating the unimplemented closures separately, the implementation reuses the existing DependencyEndpointMacro expansion and extracts the generated initializer from its synthesized peer declaration.

This means the fallback implementation always stays consistent with @DependencyEndpoint itself, including future changes to its generated code and the dynamic \(Self.self) type name used in issue reporting.

Why this approach?

The primary goal is to make conditional endpoints behave exactly like unconditional ones while preserving Swift's compilation and initialization semantics.

From a user's perspective, platform-specific endpoints become a first-class feature of @DependencyClient instead of requiring workarounds or producing surprising omissions.

I'd appreciate feedback on both the overall direction and the generated initializer strategy. In particular, if there's a simpler or more idiomatic approach to handling conditional initialization that I've overlooked, I'd love to hear thoughts.

Sample Implementation

A PR implements the behavior outlined in this discussion.

[mbrandonw]

Hi @fruitcoder, the way you have proposed things it only works if all of the #if statements are disjoint. If there is any overlap in the conditions you will get initializers that don't really work.

For example, this client:

@DependencyClient
struct Client {
  #if os(iOS) || os(tvOS)
    var fetch1: () -> Void
  #endif
  #if os(iOS)
    var fetch2: () -> Void
  #endif
}

…would not produce an initializer that allows setting fetch1 and fetch2 at the same time. On iOS you would have two separate initializers, one for fetch1 and one for fetch2.

There is no way for us to analyze the #if statements to see if each is truly mutually exclusive, and so I'm not sure this can actually be done. And there are also a lot more edge cases to think about. Such as what to do with #else/#elseif blocks and nested #ifs.

[fruitcoder]

Thanks for the input! That's indeed a problem I haven't thought about and it really isn't possible to solve this reliably, what a shame 😥 Other popular macro repos have the same "issue"

So the answer for my use case is probably: Don't use the macro and write it by hand right? 😅

[mbrandonw]

Yeah it's a bummer. I think you can close the PR unless there is some big breakthrough that makes these kinds of things possible in macros.