Support default values inside of generated DependencyEndpoint function parameters

[ollieatkinson]

When using DependencyEndpoint we specify that an associated function must be generated to help with ergonomics of using the dependency, in this, we provide the name and type of each parameter so the macro is able to generate the function.

💡 It would be nice if we were also able to provide some syntax to allow the generated function to include default values for the parameter.

struct Client {
  @DependencyEndpoint(method: "myEndpoint")
  var endpoint: (_ id: Int /* = 42 */) -> Void
}

expands to

struct Client {
  var endpoint: (_ id: Int /* = 42 */) -> Void {
    @storageRestrictions(initializes: _endpoint)
    init(initialValue) {
      _endpoint = initialValue
    }
    get {
      _endpoint
    }
    set {
      _endpoint = newValue
    }
  }
  func myEndpoint(id p0: Int = 42) -> Void {
    self.endpoint(p0)
  }
  private var _endpoint: (_ id: Int /* = 42 */) -> Void = { _ in
    XCTestDynamicOverlay.XCTFail("Unimplemented: '\(Self.self).endpoint'")
  }
}

---

I do not have much experience with SwiftSyntax to know how we can implement this, open to feedback on the idea, syntax and help on approach to implemention.

[stephencelis]

@ollieatkinson Thanks for sharing the idea! While default arguments would be a nice feature to support, I think we would want such support to leverage existing Swift features and the type system. I think generating code from comment declarations might be difficult to get right and provide good diagnostics for.

No alternatives come to mind, but we're open to further discussion if you have any.

At the end of the day, manually defining the occasional method that needs a default isn't so bad, and seems better than relying on too much macro magic. What do you think?

[ollieatkinson]

think we would want such support to leverage existing Swift features and the type system

Is it not true that the generated code would be type checked before compiling? Since macro expansion runs before the compiler.

At the end of the day, manually defining the occasional method that needs a default isn't so bad, and seems better than relying on too much macro magic. What do you think?

I think it warrants a solution, manually defining it either means:

1. You ignore via DependencyEndpointIgnored and manually implement the function and have to keep them in sync
2. You implement via DependencyEndpoint and include all n variations based on the number of arguments that have default values. Which can be tricky to manage, and easily get out of sync.

[ollieatkinson]

When wrapping an existing dependency where you want to create functions with default values, it becomes very cumbersome to manage and there's a feeling that the magic of using "DepedencyEndpoint" is lost.

[stephencelis]

Is it not true that the generated code would be type checked before compiling? Since macro expansion runs before the compiler.

It's type-checked inside the generated code, but these errors are hidden inside the expansion in Xcode and not surfaced nicely, so every error the macro fails to diagnose is a cryptic error that is more difficult for the end user to understand. You can argue this is an Xcode bug, but we're the ones that folks are going to report it to.

So I think the preference would be to leverage actual Swift syntax over taking the contents of a comment and handing it off to the compiler.

I think it warrants a solution, manually defining it either means:

1. You ignore via DependencyEndpointIgnored and manually implement the function and have to keep them in sync

I'm not sure why you need to ignore. Methods are only generated when you provide "second names" like _ count: Int, and if you're defining the method from scratch you can simply not worry about that step here.

2. You implement via DependencyEndpoint and include all n variations based on the number of arguments that have default values. Which can be tricky to manage, and easily get out of sync.

Not sure I understand this one.

When wrapping an existing dependency where you want to create functions with default values, it becomes very cumbersome to manage and there's a feeling that the magic of using "DepedencyEndpoint" is lost.

Do you have a concrete example of this? In our experience of using these macros default arguments has been enough of a minor use case where we don't mind the occasional from-scratch method. It's an occasional 3-liner that we used to write manually anyway.

Again, we're not totally opposed to enhancements here, but we would like as much to be encoded in the original Swift as possible. Even the string-y method name override feels on the brink of too magical to me.

[ollieatkinson]

So I think the preference would be to leverage actual Swift syntax over taking the contents of a comment and handing it off to the compiler.

I agree, it would be better - out of creating some DSL, I don't see an obvious way.

Do you have a concrete example of this?

struct Client {
  @DependencyEndpoint(method: "track")
  var screenEvent: (_ screenEvent: String,  _ type: ScreenType, _ tags: [Tag], _ metadata: [String: Any]) -> Void
}

-->

func track(screenEvent: String, type: ScreenType = ..., tags: [Tag] = [], metadata: [String: Any] = [:]) { ... }

You can't provide this function, because there will be a collision.

func track(screenEvent: String, type: ScreenType, metadata: [String: Any]) { ... }
func track(screenEvent: String, tags: [Tag], metadata: [String: Any]) { ... }
....

So, the decision now is - ignore the generated code, or implement the functions with pre-filled default values.

In our experience of using these macros default arguments has been enough of a minor use case

This is something thats cropped up in a lot of the use-cases so far, analytics, logging, performance, etc.

---

It could be that I am barking up the wrong tree and all of this is not worth it - but, my intuition tells me it would be a useful thing to have included as part of the macro offering.