-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Implement inheritance of initializers with generic parameters [4.2] #17390
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 inheritance of initializers with generic parameters [4.2] #17390
Conversation
@swift-ci Please test |
Build failed |
Build failed |
2a71adb
to
77d5df7
Compare
@swift-ci Please test |
Build failed |
Build failed |
77d5df7
to
3c3d31a
Compare
@swift-ci Please test |
Build failed |
Build failed |
3c3d31a
to
eb35069
Compare
@swift-ci Please test |
Build failed |
@swift-ci Please test |
eb35069
to
09aea61
Compare
Build failed |
Build failed |
@swift-ci Please test |
Build failed |
@swift-ci Please test |
} | ||
|
||
// We don't have to clone the requirements, because they're not | ||
// used for anything. |
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.
Don't they get printed sometimes? Like, for quick help?
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.
We should only be printing generic signatures, not generic parameter lists. RequirementReprs are not serialized.
superclassDepth = genericSig->getGenericParams().back()->getDepth() + 1; | ||
|
||
// We're going to be substituting the requirements of the base class | ||
// initializer to form the requirements of the derived class initializer. |
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'm clearly extra sensitive to this now because of the other issue, but what happens if the constraints can't be satisfied?
class Base<Wrapped> {
init() {}
init<Num: Numeric>(absoluteValueOf: Num) where Num.Magnitude == Wrapped {}
}
class Sub: Base<String> {}
_ = Sub(absoluteValueOf: "bac")
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.
It fails:
<unknown>:0: error: generic parameter 'Num' could not be inferred
I guess that's not great, but I'm not sure what the best solution is. Just drop the initializer?
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.
Keeping it's probably the best option for now. Who knows what would happen if it was required
?
Fixes https://bugs.swift.org/browse/SR-3848.