-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Implement type normalization #15
base: main
Are you sure you want to change the base?
Implement type normalization #15
Conversation
Hey Alessio, happy to review this PR but I've just been holding off cause it's still marked as a draft. Just letting you know in case that was an accident 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking awesome so far! 🚀 It seems like you've caught most of the edge cases 👌 I've left some comments with a few more edge cases to test out and some aspects of normalization that I think should be changed to make things a bit easier to use or more intuitive. If there's anything that doesn't make sense or you don't agree with, don't hesitate to let me know! Always happy to have a more in-depth discussion.
return .packReference(.init(type._baseSyntax, attributedSyntax: type._attributedSyntax)) | ||
case .simple(let type): | ||
if type.name == "Void" { | ||
return .tuple(.init(.init(elements: []))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Void
is better to have as a simple type as that's the name most people know it by (and using ()
is considered less swift-y by a few core Swift contributors, even though Void
is actually an alias to ()
under-the-hood).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #15 (comment).
Hmm that does complicate my suggestion for |
I found useful to use string representations of types in my code to avoid misspelling types and keeps cases as type-safe as possible. In my code using the package I have, for example: switch (typeName) {
case ("\(Int.self)"):
getterBody = "integer(forKey: Self.\(identifierTokenSyntax)Key)"
case ("\(Bool.self)"):
getterBody = "bool(forKey: Self.\(identifierTokenSyntax)Key)"
case ("\([String: Any].self)", true):
getterBody = "dictionary(forKey: Self.\(identifierTokenSyntax)Key)"
Even considering that |
Yeah that is a tricky distinction to make. The way that I'm looking at it is that the two concurrent goals for the normalisation are to minimise the number of special cases (i.e. removing specialised As I see it, normalisation now has only a single way of representing every type (ignoring the possibility for unnecessary single-element tuple syntax), except for void; macro toolkit has to make a choice between either To me, comparing a type against If choosing one option or the other eliminated an enum case from I guess if you look at it from the 'reducing the number of special cases' point of view then representing void as I'll attempt to do a bit of polling among Swifties that I know and see what people reckon. |
Implement basic type normalization, as discussed in #7.
The
Type.normalized()
function mapsType
elements to their correspondingNormalizedType
so that syntax that has the same semantic meaning is mapped to the same syntax underNormalizedType
.The implementation, when it makes sense, tries to keep as much information as possible during the mapping, trivias included.
As a source of truth for what the normalized version should be, I used, where possible, the result obtained by printing the type to the console, for example:
and
Closes #7.