fix #15959

[cooldome]

Please review the approach. My knowledge of generics is still lacking.
I have added typeFromExpr for subscript operator, but I was getting cannot Eval error from the vm in replaceTypeVarsTAux.

Because of this I have patched replaceTypeVarsTAux to call semExpr instead of semConstExpr and use semConstExpr only if needed. This step I am not sure about.

[timotheecour]

this doesn't fix #15959, only a particular case. Commit + PR should be changed to refs #15959, many examples there still don't work.
But I don't think special casing subscript operator is a good idea, a general fix is needed otherwise you'll end up with lots of complexity to handle the other cases similarly.

typeFromExpr is indeed the proper fix, but it should be applied in the general case, perhaps as a catch-all.

[cooldome]

I have tried catch all typeFromExpr, it creates a lot more problems than fixes.
Special casing for subscrit is required because sem has special case for it, if a[0] was a generic function call than special casing would not be required. BracketExpr remains special expression, so its type.

[cooldome]

Test failure is unrelated

[timotheecour]

either way, this still holds:

this doesn't fix #15959, only a particular case. Commit + PR should be changed to refs #15959, many examples there still don't work.

[Araq]

That seems to be a bad idea, can't we add a better proc/syntax/interface to tyGenericParam. The [] is very overloaded already, seems to be recipe for desaster.

[cooldome]

Not sure I understand. If [] was a proc defined in system then this change wouldn't be required, but nkBracketExpr is still the special beast that is handled by its own rules. These rules don't handle tyGenericParam, hence the fix.

Another solution would be to define all missing procs in system.nim

proc `[]`[T: tuple](x: T, i: int): T {.magic: "XXX".}

Possibly others and then remove most of semSubscript and rely on operator overloading.
Not sure this change will be easy and go smoothly though.

[timotheecour]

[] special rules indeed cause a lot of issues (eg #15911) and should be replaced by proper overloading (of possibly magic procs)

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.