Skip to content
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

fix for Element compiler issue #185

Merged
merged 1 commit into from
Jul 19, 2024

Conversation

iwt-dahlborn
Copy link
Contributor

@iwt-dahlborn iwt-dahlborn commented Jul 19, 2024

This would be the general idea with a very rough implementation. Basically just generating a typealias for every associated value that contains an Element type.

It could be refined to check if there is specifically a type named Element used since this will just catch anything containing element.

I think the macro definition can also better specify what names the typealias can have so it doesnt need to be arbitrary?

Like I said just a very rough idea.

edit: Sorry just saw that my formatter ran a bit wild there

@mbrandonw
Copy link
Member

Hey @iwt-dahlborn, how do you feel about tweaking this PR slightly so that rather than introducing a bunch of type aliases for each payload we just stick with the one _$Element type alias, and then replace occurrences of Element in the payloads with _$Element:

-public var element: CasePaths.AnyCasePath<Action, _$elementElement> {
+public var element: CasePaths.AnyCasePath<Action, (_$Element, Int)> {

Copy link
Member

@stephencelis stephencelis 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 diving into this!

I think ideally we would avoid the arbitrary naming in the macro and preserve the simpler _$Element type alias if possible. Any reason this can't be done?

I was thinking we could detect an Element type referenced inside AllCasePaths and we could replace them all with _$Element. There's already a SelfRewriter that replaces instances of Self with the enum name, and I think we could generalize it to do this job as well:

https://github.com/pointfreeco/swift-case-paths/blob/main/Sources/CasePathsMacros/CasePathableMacro.swift#L471-L483

And then if it rewrites at least one Element, the macro would also insert the type alias in the parent.

Wanna give that a shot?

To avoid collision with `Sequence` associated type `Element`
@iwt-dahlborn
Copy link
Contributor Author

iwt-dahlborn commented Jul 19, 2024

I updated the pull request with the rewriter based method you proposed and I think it definitely seems to be the most elegant solution.

While doing the changes I was wondering why the AllCasePath declarations default to a public access level instead of reusing the access level of the enum.

@iwt-dahlborn iwt-dahlborn marked this pull request as ready for review July 19, 2024 17:15
@stephencelis
Copy link
Member

Thanks!

While doing the changes I was wondering why the AllCasePath declarations default to a public access level instead of reusing the access level of the enum.

We've found this to be the most convenient way to automate the access level, and Apple follows the convention in some of its macros (@Model, I believe). We used to match the access level but then we needed to update all our macros when package access was introduced, and we've also noticed issues around parent contexts (like private extension) that the macro is unaware of.

Copy link
Member

@stephencelis stephencelis left a comment

Choose a reason for hiding this comment

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

Looks good!

@stephencelis stephencelis merged commit 19c82b0 into pointfreeco:main Jul 19, 2024
2 checks passed
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