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

Generic parameters now can constrain statics in type definitions #19362

Merged
merged 2 commits into from
Jan 13, 2022

Conversation

beef331
Copy link
Collaborator

@beef331 beef331 commented Jan 10, 2022

Prior to this the types were not capable of being instantiated.
Partially addresses #7209 though the following still errors

proc doThing[T; Y: static T]() = discard
doThing[int, 100]()

resolved regression with generic procedures
@@ -1739,11 +1739,22 @@ proc typeRel(c: var TCandidate, f, aOrig: PType,
let prev = PType(idTableGet(c.bindings, f))
if prev == nil:
if aOrig.kind == tyStatic:
if f.base.kind != tyNone:
if f.base.kind notin {tyNone, tyGenericParam}:
result = typeRel(c, f.base, a, flags)
Copy link
Member

Choose a reason for hiding this comment

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

Why was this line not good enough?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I believe my other comment should answer this.

result = typeRel(c, f.base, a, flags)
if result != isNone and f.n != nil:
if not exprStructuralEquivalent(f.n, aOrig.n):
result = isNone
elif f.base.kind == tyGenericParam:
# Handling things like `type A[T; Y: static T] = object`
Copy link
Member

Choose a reason for hiding this comment

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

These things should have been taken care of by the line:

result = typeRel(c, f.base, a, flags)

Already. This solution of yours is very good in that it improves the current situation, but it's an ad-hoc bandaid.

Copy link
Collaborator Author

@beef331 beef331 Jan 11, 2022

Choose a reason for hiding this comment

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

The information is lost in the future steps so eventually it gets T vs. T which is ok to solve with a change to the tyTypedesc branch, but it then gets typedesc[int] vs. int literal (2) without knowing either side is static. Seems the only place to solve it is inside the tyStatic anywhere lower just lacks the knowledge to know to check the children types. Solving the typedesc[int] vs. int literal just causes a bunch of issues with other generics for obvious reasons that values equate types. There very well might be a better solution, I've combed over typerel trying to find it but just hit that wall of lack of information to reason the relation.

compiler/sigmatch.nim Outdated Show resolved Hide resolved
@Araq Araq added the merge_when_passes_CI mergeable once green label Jan 13, 2022
@ringabout ringabout merged commit a93f6e7 into nim-lang:devel Jan 13, 2022
PMunch pushed a commit to PMunch/Nim that referenced this pull request Mar 28, 2022
…-lang#19362)

* Parameters now can constrain static in type definitions

resolved regression with generic procedures

* Update compiler/sigmatch.nim

Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
narimiran pushed a commit that referenced this pull request Apr 24, 2023
)

* Parameters now can constrain static in type definitions

resolved regression with generic procedures

* Update compiler/sigmatch.nim

Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
(cherry picked from commit a93f6e7)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge_when_passes_CI mergeable once green
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants