v2.0.10 regression `ambiguous call; both system.==(x: T: tuple or object, y: T: tuple or object) ... and h.==(x: T: J, y: T: J) ... match for: (J, J)`

[tersec]

Description

h.nim:

type J* = object
func `==`*[T: J](x, y: T): bool = discard

Then:

import ./h
discard J() == J()

Per https://nim-lang.org/docs/manual.html#overload-resolution documents neither of these are "exact" or "liiteral" matches, but the overload in h.nim is a

Generic match: f is a generic type and a matches, for instance a is int and f is a generic (constrained) parameter type (like in [T] or [T: int|char]).

so it at least isn't a worse match than system.==(x: T: tuple or object, y: T: tuple or object), though it seems like by https://nim-lang.org/docs/manual.html#overload-resolution-first-trialcolon-catagory-matching [1] the object overload in system would be instead the next-lower-down category by subtypes, at least, that's the closest the manual gets to describing the situation precisely:

Subrange or subtype match: a is a range[T] and T matches f exactly. Or: a is a subtype of f.

But even if that's a tie, then https://nim-lang.org/docs/manual.html#overload-resolution-first-trialcolon-catagory-matching [2] would tip things to the h.nim generic overload.

So according to any version either before or after precisely v2.0.10, and by the documentation, this should not be an ambiguous overload.

[1] "category"
[2] "trail" in body text?

Nim Version

Builds:
v2.0.8:

Nim Compiler Version 2.0.8 [Linux: amd64]
Compiled at 2024-10-03
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: 5935c3bfa9fec6505394867b23510eb5cbab3dbf
active boot switches: -d:release

version-2-2:

Nim Compiler Version 2.2.0 [Linux: amd64]
Compiled at 2024-10-03
Copyright (c) 2006-2024 by Andreas Rumpf

git hash: 78983f1876726a49c69d65629ab433ea1310ece1
active boot switches: -d:release

devel:

Nim Compiler Version 2.2.1 [Linux: amd64]
Compiled at 2024-10-03
Copyright (c) 2006-2024 by Andreas Rumpf

git hash: d6a71a10671b66ee4f5be09f99234b3d834e7fce
active boot switches: -d:release

Does not build:

Nim Compiler Version 2.0.10 [Linux: amd64]
Compiled at 2024-10-03
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: e941ee15be775fe3c46db1bed9b4f41c7dfb1334
active boot switches: -d:release

Current Output

/tmp/v.nim(2, 13) Error: ambiguous call; both system.==(x: T: tuple or object, y: T: tuple or object) [proc declared in /tmp/nim2010/lib/system.nim(1715, 6)] and h.==(x: T: J, y: T: J) [func declared in /tmp/h.nim(2, 6)] match for: (J, J)

Expected Output

No response

Known Workarounds

No response

Additional Information

No response

[metagn]

Very likely works in 2.2+ because of #22143, which was not backported. If this is considered too large to backport, one or all of #22261, #23173, #23033, #23137, #23870, #24144 can be reverted from 2.0, since they likely depend on it to work.

[narimiran]

If this is considered too large to backport

I'll give it a try, and if I don't succeed, then we'll think about the alternatives.

[narimiran]

The backporting of #22143 was successful. It should now work in 2.0.11.