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

Concept requirements ignored in some cases #7014

Open
RedBeard0531 opened this issue Jan 2, 2018 · 1 comment
Open

Concept requirements ignored in some cases #7014

RedBeard0531 opened this issue Jan 2, 2018 · 1 comment
Assignees
Labels

Comments

@RedBeard0531
Copy link
Contributor

This shouldn't compile but does with both 0.17.2 and devel:

type
  Holder[T] = object
  Concept[Arg] = concept c, type C
    c is C
    false

proc test(holder:Holder, _: Concept[holder.T]) = discard

test(Holder[string](), 1)
@RedBeard0531
Copy link
Contributor Author

BTW, this is the real code I'm trying to make work:

  HashEqCompatible*[StorageType] = concept heq, type HEQ
    ## Declares types where a == b implies hash(a) == hash(b), even with
    ## different types. For example, string and cstring are compatible.
    mixin isHashEqCompatible
    HEQ is StorageType or
      isHashEqCompatible(type StorageType, type HEQ) or
      isHashEqCompatible(type HEQ, type StorageType)

    hash(heq) is Hash
    (heq == StorageType) is bool

The goal is that you need to explicitly opt in to being compatible because it isn't guaranteed by the signatures of the functions. Is there a better way to allow explicit opt-in to a Concept by a pair of types?

@zah zah self-assigned this Jan 2, 2018
@zah zah added the Concepts label Jan 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants