Changing generic weight of tyGenericParam

[Graveflo]

This is in reference to a feature request that I posted.

I'm making this PR to demonstrate the suggested change and expect that this should be scrutinized

[Graveflo]

On the CI failure, there is a test in the Nim codebase under tests/macros/tgetimpl that passes len as a typed parameter to a macro and then uses the expression y.owner where the parameter is y, as if len will not have other candidates. I'm not sure why this compiles with the current version in nim. It is given the nnkSym node kind in current nim and nnkClosedSymChoice in the PR'd version of nim. I'm still looking into the datamancer failure

Also, I know the test file is a little bit messed up. If preferable I can get rid of some of those "anti-regression" tests and I will fix the while true block inside of the block that I made.

Also, if this ends up working I think I should add a blurb to the manual

[Araq]

Also, if this ends up working I think I should add a blurb to the manual

You really should start with the manual/spec.

[Graveflo]

Is there a formal spec? I looked but all I could find was the manual.
I'll add some text to the manual that talks about some of the pieces involved in this, as I think that clarification would be helpful in multiple ways.
To be clear, I don't think that I am trying to do make nim behave off-spec as it is described in the manual. It is a breaking change, but not contradicting the manual as far as I know. The test cases (barring the "anti regression" mess) are good isolated examples of what nim currently does vs what I assume it should do.
Also, I want to make sure I have my terminology correct here, because this should be important when explaining things in the manual. Is this accurate for the "anatomy of a call":

p[T: t](arg1: f): y

p: callee symbol

[...]: constraints

T: t: constraint

(arg1: f): y: formal signature

arg1: f: formal parameters

f: formal parameter type

y: formal return type

After matching / resolution the "formal" parameters that are not concrete crystalize into call-specific bindings.

[Araq]

Is there a formal spec? I looked but all I could find was the manual.

The manual is the spec. Could be more formal, we're getting there by telling contributors to write spec'y documentation.

[Araq]

It is:

p: callee symbol

[...]: generic parameters

T: t: generic constraint

[T: t](arg1: f): y: (formal) signature

arg1: f: (formal) parameter

f: (formal) parameter type

y: (formal) return type

[Graveflo]

Alright, thank you and T is described as a "type variable" in the manual. This issue was a bit more complex then I realized.
I am going to:

• Give the manual another look and see if there is more I can clarify there
• Look at the datamancer failure in the CI but it is a web of macros that is hard to parse
• Change the tgetimpl test to use something other then len because it has more then one candidate, so I think owner doesn't make sense there
• Maybe make another issue with a condensed version of the bug in tgetimpl and make test cases for it, although I have no idea why it is currently accepted by the compiler
• Look into other type classes in typeRel because I only modified how object behaves there and other type classes might need similar treatment

If I can iron out that list I might be done with this. For a first pass at least.

If anyone thinks that test in tgetimpl should actually work or has info about the datamancer failure feel free to let me know

[Graveflo]

PR #23033 appears to fix datamancer on this PR. As far as I know that is the last caveat here, so this should be ready if/when that gets merged

[Araq]

I'm merging this but it needs a follow PR as the documentation is incomprehensible. Also, the whole approach is kinda nuts (not your fault, of course). Instead we need a formal type relation isMoreSpecific(a, b) that describes the effects, not how it's implemented.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 74fa8ed

Hint: mm: orc; opt: speed; options: -d:release
177654 lines; 7.541s; 768.129MiB peakmem

[Graveflo]

we need a formal type relation isMoreSpecific(a, b) that describes the effects, not how it's implemented.

Just for posterity and to throw an idea out there: The hypothetical function isMoreSpecific maps to checkGeneric in the compiler source. Specificity is a hierarchical rank. typeRel defines a hierarchy implicitly and checkGeneric enforces it explicitly in overload resolution, so these two functions should be the same.

Documenting "specificity" would be 99% documenting typeRel which is an interesting prospect considering as how complex it is, and it's current documentation status. There's more that can be said about this but I wouldn't go into further detail with this prompting.

Also, for the record, I don't like the way specificity sounds in these contexts. I'm the one that started saying it, so not blaming anyone but me for that. Still, it does seem to fit the idea well enough.

#23171