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 some issues overloading with generics and inheritance #15211

Merged
merged 2 commits into from
Aug 27, 2020

Conversation

jcosborn
Copy link
Contributor

No description provided.

@@ -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)
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

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

Alright.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@Araq Araq merged commit d11933a into nim-lang:devel Aug 27, 2020
mildred pushed a commit to mildred/Nim that referenced this pull request Jan 11, 2021
…5211)

* fix some issues overloading with generics and inheritance

* fix passing procs with subtype matches
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