Skip to content

Resolves issue with endpoints not reporting errors when there's a custom closure #355

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 7, 2025

Conversation

gpambrozio
Copy link
Contributor

@gpambrozio gpambrozio commented Apr 5, 2025

Resolves issue #183

After getting feedback from the swift team on an issue that seems to be on the swift side I modified the endpoint macro to follow their advice. Simply removing the member initializer accessor.

I also modified all tests so they pass.

I tested on a project that uses dependencies a lot and it all still works. I also tested removing some unimplemented from my closures and checking if tests fail and they do.

Not sure if DependencyClientTest is still necessary but keeping it to allow the maintainers to decide.
@gpambrozio gpambrozio changed the title Resolves issue #183 Resolves issue with endpoints not reporting errors when there's a custom closure Apr 5, 2025
Copy link
Member

@mbrandonw mbrandonw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking care of this so quickly @gpambrozio!

@mbrandonw mbrandonw merged commit fee6aa2 into pointfreeco:main Apr 7, 2025
7 checks passed
@AgapovOne
Copy link

This actually breaks some dependencies that were declared before, i.e.:

struct Client {
  var someProperty: Int
  @DependencyEndpoint
  var endpoint: () -> Void
}

public func doX() {

  let client1 = Client(someProperty: 0, _endpoint: { print("doY") })
  let client2 = Client(someProperty: 0, endpoint: { print("doY") })
}

I could have used init before for client2, now both inits break:

Screenshot Screenshot 2025-04-22 at 14 18 01

Only custom init would help here, where i should write self._endpoint = endpoint. I would prefer if init with endpoint name without underscore is used still, because that macro alone helps in some places where we want to use functions.

@mbrandonw
Copy link
Member

Hi @AgapovOne, good catch! Thanks for letting us know.

It seems that for people using @DependencyEndpoint directly without @DependencyClient we do need the init accessor. However, I'm curious... why aren't you using @DependencyClient? Can you? And if not, then you can just use unimplemented directly:

struct Client {
  var someProperty: Int
  @DependencyEndpoint
  var endpoint: () -> Void = unimplemented("Unimplemented: \(Self.self).endpoint")
}

One way to fix this would be to add an option to the macro: @DependencyEndpoint(initAccessor: Bool). It would default to true to restore backwards compatibility, and then @DependencyClient would use @DependencyEndpoint(initAccessor: false). Do you have any interest in tackling this problem?

@AgapovOne
Copy link

AgapovOne commented Apr 23, 2025

Here's an example of dependency where I can't use @DependencyClient, because I don't know a default for ValueType:

struct SettingWritable<ValueType: Codable & Equatable & Sendable> {
  public var value: () -> ValueType
  @DependencyEndpoint
  public var set: (ValueType?) -> Void
}

Good idea with boolean parameter, I'll try to look into macro arguments and somehow fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants