Skip to content

[Concepts] Consider concept declarations for name resolution #392

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

Open
konsumlamm opened this issue Jun 27, 2021 · 4 comments
Open

[Concepts] Consider concept declarations for name resolution #392

konsumlamm opened this issue Jun 27, 2021 · 4 comments

Comments

@konsumlamm
Copy link

Motivation

Currently, the following example fails to compile (see nim-lang/Nim#17420):

type
  Comparable = concept
    proc compare(a, b: Self): int # so that there are no conflicts with `cmp`

proc test[T: Comparable](x, y: T) =
  echo compare(x, y) # Error: undeclared identifier: 'compare'

The reason is that the declarations in a concept body are not considered for name resolution. However, this would be very useful for defining concepts and functions that operate on types implementing the concept, without having such a type in scope.

Solution

Concepts define a dummy proc that is considered for name resolution. It wouldn't need to return anything useful, since it can only be called when the concept is implemented for the type it's called with anyway. This could either be done by generating a proc that just returns the default value of the return type (although this wouldn't work when you can define types without a default value, see #290 and #252) or by using compiler magic.

@Araq
Copy link
Member

Araq commented Jun 27, 2021

Why not instead let the concepts inject a set of mixin declarations inside the procs that use the concept?

@konsumlamm
Copy link
Author

konsumlamm commented Jun 27, 2021

Why not instead let the concepts inject a set of mixin declarations inside the procs that use the concept?

If that works, sure, I've just never used mixin. I don't have any strong preference for the implementation, let's do whatever works well.

EDIT: Looking at the documentation for mixin, that seems to be exactly the mechanism we want here.

@konsumlamm
Copy link
Author

@Araq is there anything blocking this?

@Araq
Copy link
Member

Araq commented Nov 17, 2021

Feel free to give it a try, the core team has currently no capacity to work on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants