pointfreeco / swift-issue-reporting

Report issues in your application and library code as Xcode runtime warnings, breakpoints, assertions, and do so in a testable manner.
https://www.pointfree.co
MIT License
368 stars 60 forks source link

Use parameter pack in place of generic arguments with limit of 5 #82

Closed AgapovOne closed 4 months ago

AgapovOne commented 4 months ago

Parameter pack implementation

Parameter packs are implemented in Swift 5.9.

That means we can reduce code to just one method of one type and remove limit on 5 arguments in generic calls.

Now any number of arguments is handled with unimplemented, there will be no limit of 5 arguments

First mention about increasing limit is in PR #65

Current state

I removed all unimplemented methods with more than one parameter and with zero parameters, because (repeat each A) means it could be 0 values (Void) or any other number.

Only test that fails is one that records failure but xctestexpectfailure said it doesn't record failure. That's strange. Attaching a screenshot of the issue.

Only failed test

Screenshot 2024-04-23 at 12 35 45

That happens only with simple () -> Int closure.

let f00: () -> Int = unimplemented("f00", placeholder: 42)
AgapovOne commented 4 months ago

Test actually failed only because now tuple with zero values is added to message and Invoked with: is added.

Don't know if that would be so bad to know that tuple has no arguments. You could say we can strip Invoked with: message if tuple is zero. If so, I can edit the code to do so.

Now the tests build and run. 5 are succeeded, 5 are expected failures. As in main branch.

stephencelis commented 4 months ago

@AgapovOne Thanks for exploring!

We actually consider unimplemented to be deprecated these days, for swift-dependencies' [@DependencyClient](https://swiftpackageindex.com/pointfreeco/swift-dependencies/main/documentation/dependenciesmacros/dependencyclient()) (and @DependencyEndpoint) macros, which can generate and diagnose code better at compile time. We should add soft deprecations to these functions to better communicate this.

Also, there is a Swift type-checking bug in which unimplemented combined with .init abbreviation can lead to exponential compile times, and we think it applies even without the current overloads, so we were hoping to retire this tool soon so that folks can avoid that trap.

Does that make sense? Any questions?

AgapovOne commented 4 months ago

Totally fine by me, it's your library and your vision.

Thank you for the explanation on next steps.

stephencelis commented 4 months ago

Thanks! Going to close this for now, but appreciate your exploration all the same :smile: