-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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 some issues overloading with generics and inheritance #15211
Conversation
@@ -296,6 +317,9 @@ proc cmpCandidates*(a, b: TCandidate): int = | |||
# the other way round because of other semantics: | |||
result = b.inheritancePenalty - a.inheritancePenalty | |||
if result != 0: return | |||
# check for generic subclass relation | |||
result = checkGeneric(a, b) |
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.
Please outline why the simple counting approach that sumGeneric
currently implements does not suffice for generic inheritance.
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.
Currently sumGeneric
favors Bar[bool or int]
over either Bar[int]
or Bar[T]
. That could be fixed to favor Bar[int]
, but it couldn't really distinguish between Bar[bool or int]
and Bar[T]
. Also it can easily be fooled with aliases like type Id[T]=T
so that Bar[Id[T]]
would win over Bar[T]
even though they are really equivalent. Fixing that would require more work. In the end it seemed that just using typeRel
would solve all of these issues and be the more robust solution.
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 fear potential wasteful or infinite recursions. Can't we have some specialized code dealing with this problem?
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.
sumGeneric
isn't called from typeRel
, so I don't think infinite recursion is possible. We need to directly compare the two constraints, so some form of typeRel
is needed. I'm not sure how much could be removed and still work correctly. If you are worried about the performance, we could try splitting out some of the most common cases from typeRel
and make them callable directly or from within typeRel
so that they can be reused, or maybe just make common paths in typeRel
faster. I'm wary of duplicating it since that just makes more code to debug later (there are several more bugs in generics that still need to be fixed). I'd prefer to start with something that is as correct as possible before trying to optimize it too much.
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.
Alright.
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.
With this PR https://play.nim-lang.org/#ix=2vwQ hits an infinite recursion.
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.
This should be fixed by #15241.
…5211) * fix some issues overloading with generics and inheritance * fix passing procs with subtype matches
No description provided.