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

[ABI] Initial draft of canonicalization and minimization of generic signatures #12740

Merged
merged 3 commits into from
Nov 4, 2017

Conversation

DougGregor
Copy link
Member

@DougGregor DougGregor commented Nov 3, 2017

This is a rough, initial draft describing the canonicalization and minimization of generic signatures for the purposes of the ABI. Comments greatly appreciated!

Addresses the documentation part of SR-3733 and rdar://problem/31412994.

2. Constraints follow, ordered first by the
[type parameter ordering](#type-parameter-ordering) of the left-hand
operand and then by constraint kind. The left-hand side of a constraint
is always a type parameter `T`, which can be a generic parameter of a
Copy link
Contributor

Choose a reason for hiding this comment

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

"a generic parameter or a"?

Copy link
Member Author

Choose a reason for hiding this comment

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

Got it, thanks.

nested type thereof (e.g., `T.SubSequence.Iterator.Element`).
Constraints are ordered as follows:
1. A superclass constraint `T: C`, where `C` is a class.
2. A layout constraints (e.g., `T: some-layout`), where the right-hand
Copy link
Contributor

Choose a reason for hiding this comment

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

"A layout constraint"

Copy link
Member Author

Choose a reason for hiding this comment

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

Got it, thanks.


### Same-type constaints

The canonical form of superclass, layout, and conformance constraints are trivially canonicalized using the anchor of the appropriate equivalence class. Same-type constraints, on the other hand, are responsible for forming those equivalence classes. Let's expand our running example to include a third `Collection`:
Copy link
Contributor

Choose a reason for hiding this comment

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

What about superclass constraints where the right hand side is a generic class?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I should call that out. The RHS needs to be a canonical concrete type.

@slavapestov
Copy link
Contributor

It's not clear to me how we canonicalize concrete structural types that contain type parameters inside of them, eg T.Foo == (T.Bar, T.Baz). Does that fall out from the other rules or does it deserve a mention? Either way an example would be good.

@DougGregor
Copy link
Member Author

Canonicalizing concrete structural types containing type parameters needs to be called out. I'll push an update shortly that does so, thanks!

@DougGregor
Copy link
Member Author

I think this is in "good enough" shape to merge. Additional comments are certainly welcome!

@DougGregor DougGregor merged commit 1d8bc93 into swiftlang:master Nov 4, 2017
@DougGregor DougGregor deleted the abi-generic-signatures branch November 4, 2017 05:28
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.

2 participants