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

Cannot select the right procedure overload when using concepts. #14729

Closed
bobeff opened this issue Jun 19, 2020 · 1 comment · Fixed by #24315
Closed

Cannot select the right procedure overload when using concepts. #14729

bobeff opened this issue Jun 19, 2020 · 1 comment · Fixed by #24315
Labels

Comments

@bobeff
Copy link
Contributor

bobeff commented Jun 19, 2020

There is a problem with selecting the right overload of hash and == for a generic objects inferred by a concept.

The not working example is as follows:

import sets, hashes

type
  Iterable[T] = concept x
    for value in items(x):
      type(value) is T

  Foo[T] = object
    t: T

proc myToSet[T](keys: Iterable[T]): HashSet[T] =
  for x in items(keys): result.incl(x)

proc hash[T](foo: Foo[T]): Hash =
  echo "specific hash"

proc `==`[T](lhs, rhs: Foo[T]): bool =
  echo "specific equals"

let
  f = Foo[string](t: "test")
  hs = [f, f].myToSet()
/some_path/nimtest/comilerbug.nim(22, 14) template/generic instantiation of `myToSet` from here
/some_path/nimtest/comilerbug.nim(12, 31) template/generic instantiation of `incl` from here
/some_path/Nim/lib/pure/collections/setimpl.nim(49, 21) template/generic instantiation of `rawGet` from here
/some_path/Nim/lib/pure/collections/hashcommon.nim(73, 14) template/generic instantiation of `genHashImpl` from here
/some_path/Nim/lib/pure/collections/hashcommon.nim(63, 12) Error: type mismatch: got <Foo>
but expected one of: 
proc hash(sBuf: string; sPos, ePos: int): Hash
  first type mismatch at position: 1
  required type for sBuf: string
  but expression 'key' is of type: Foo
proc hash(x: cstring): Hash
  first type mismatch at position: 1
  required type for x: cstring
  but expression 'key' is of type: Foo
proc hash(x: float): Hash
  first type mismatch at position: 1
  required type for x: float
  but expression 'key' is of type: Foo
proc hash(x: pointer): Hash
  first type mismatch at position: 1
  required type for x: pointer
  but expression 'key' is of type: Foo
proc hash(x: string): Hash
  first type mismatch at position: 1
  required type for x: string
  but expression 'key' is of type: Foo
proc hash[A](aBuf: openArray[A]; sPos, ePos: int): Hash
  first type mismatch at position: 1
  required type for aBuf: openArray[A]
  but expression 'key' is of type: Foo
proc hash[A](s: HashSet[A]): Hash
  first type mismatch at position: 1
  required type for s: HashSet[hash.A]
  but expression 'key' is of type: Foo
proc hash[A](s: OrderedSet[A]): Hash
  first type mismatch at position: 1
  required type for s: OrderedSet[hash.A]
  but expression 'key' is of type: Foo
proc hash[A](x: openArray[A]): Hash
  first type mismatch at position: 1
  required type for x: openArray[A]
  but expression 'key' is of type: Foo
proc hash[A](x: set[A]): Hash
  first type mismatch at position: 1
  required type for x: set[A]
  but expression 'key' is of type: Foo
proc hash[T: Ordinal | enum](x: T): Hash
  first type mismatch at position: 1
  required type for x: T: Ordinal or enum
  but expression 'key' is of type: Foo
proc hash[T: proc](x: T): Hash
  first type mismatch at position: 1
  required type for x: T: proc
  but expression 'key' is of type: Foo
proc hash[T: tuple](x: T): Hash
  first type mismatch at position: 1
  required type for x: T: tuple
  but expression 'key' is of type: Foo
proc hash[T](foo: Foo[T]): Hash
  first type mismatch at position: 1
  required type for foo: Foo[hash.T]
  but expression 'key' is of type: Foo

expression: hash(key)

If the type Foo is not generic the example works Ok

import sets, hashes

type
  Iterable[T] = concept x
    for value in items(x):
      type(value) is T

  Foo = object
    t: string

proc myToSet[T](keys: Iterable[T]): HashSet[T] =
  for x in items(keys): result.incl(x)

proc hash(foo: Foo): Hash =
  echo "specific hash"
    
proc `==`(lhs, rhs: Foo): bool =
  echo "specific equals"

let
  f = Foo(t: "test")
  hs = [f, f].myToSet()

producing the output:

specific hash
specific hash
specific equals

The same output is expected for the version when the type Foo is generic.

Alternatively if the Foo is generic but instead using a concept for myToSet parameter, an operArray parameter is used the example also works correct:

import sets, hashes

type
  Foo[T] = object
    t: T

proc myToSet[T](keys: openArray[T]): HashSet[T] =
  for x in items(keys): result.incl(x)

proc hash[T](foo: Foo[T]): Hash =
  echo "specific hash"

proc `==`[T](lhs, rhs: Foo[T]): bool =
  echo "specific equals"

let
  f = Foo[string](t: "test")
  hs = [f, f].myToSet()

specific hash
specific hash
specific equals

This issue is blocking #14481

$ nim -v
Nim Compiler Version 1.3.5 [Linux: amd64]
Compiled at 2020-06-19
Copyright (c) 2006-2020 by Andreas Rumpf

git hash: 99c198625c602984578f9c53b05a28c54de4f4cb
active boot switches: -d:release -d:danger
@bobeff
Copy link
Contributor Author

bobeff commented Jun 19, 2020

I managed to workaround a few similar issues when working on #14481, but despite putting a huge amount of effort I didn't manage to find how to overcome this on a library level. Maybe a fix in the compiler is needed.

@Araq Araq closed this as completed in 2864830 Oct 25, 2024
narimiran pushed a commit that referenced this issue Jan 14, 2025
closes nim-lang/RFCs#380, fixes #4773, fixes
#14729, fixes #16755, fixes #18150, fixes #22984, refs #11167 (only some
comments fixed), refs #12620 (needs tiny workaround)

The compiler gains a concept of root "nominal" types (i.e. objects,
enums, distincts, direct `Foo = ref object`s, generic versions of all of
these). Exported top-level routines in the same module as the nominal
types that their parameter types derive from (i.e. with
`var`/`sink`/`typedesc`/generic constraints) are considered attached to
the respective type, as the RFC states. This happens for every argument
regardless of placement.

When a call is overloaded and overload matching starts, for all
arguments in the call that already have a type, we add any operation
with the same name in the scope of the root nominal type of each
argument (if it exists) to the overload match. This also happens as
arguments gradually get typed after every overload match. This restricts
the considered overloads to ones attached to the given arguments, as
well as preventing `untyped` arguments from being forcefully typed due
to unrelated overloads. There are some caveats:

* If no overloads with a name are in scope, type bound ops are not
triggered, i.e. if `foo` is not declared, `foo(x)` will not consider a
type bound op for `x`.
* If overloads in scope do not have enough parameters up to the argument
which needs its type bound op considered, then type bound ops are also
not added. For example, if only `foo()` is in scope, `foo(x)` will not
consider a type bound op for `x`.

In the cases of "generic interfaces" like `hash`, `$`, `items` etc. this
is not really a problem since any code using it will have at least one
typed overload imported. For arbitrary versions of these though, as in
the test case for #12620, a workaround is to declare a temporary
"template" overload that never matches:

```nim
# neither have to be exported, just needed for any use of `foo`:
type Placeholder = object
proc foo(_: Placeholder) = discard
```

I don't know what a "proper" version of this could be, maybe something
to do with the new concepts.

Possible directions:

A limitation with the proposal is that parameters like `a: ref Foo` are
not attached to any type, even if `Foo` is nominal. Fixing this for just
`ptr`/`ref` would be a special case, parameters like `seq[Foo]` would
still not be attached to `Foo`. We could also skip any *structural* type
but this could produce more than one nominal type, i.e. `(Foo, Bar)`
(not that this is hard to implement, it just might be unexpected).

Converters do not use type bound ops, they still need to be in scope to
implicitly convert. But maybe they could also participate in the nominal
type consideration: if `Generic[T] = distinct T` has a converter to `T`,
both `Generic` and `T` can be considered as nominal roots.

The other restriction in the proposal, being in the same scope as the
nominal type, could maybe be worked around by explicitly attaching to
the type, i.e.: `proc foo(x: T) {.attach: T.}`, similar to class
extensions in newer OOP languages. The given type `T` needs to be
obtainable from the type of the given argument `x` however, i.e.
something like `proc foo(x: ref T) {.attach: T.}` doesn't work to fix
the `ref` issue since the compiler never obtains `T` from a given `ref
T` argument. Edit: Since the module is queried now, this is likely not
possible.

---------

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

Successfully merging a pull request may close this issue.

2 participants