I've now documented the full spec of the concepts that I'm aiming to implement:
[https://github.com/nim-lang/Nim/blob/generic-concepts/doc/manual/generics.txt#L200](https://github.com/nim-lang/Nim/blob/generic-concepts/doc/manual/generics.txt#L200) I suggest that your read it first in order to better understand the rationale behind my answers below. I hope to have everything implemented within two weeks from now - the only area where I'm not fully confident in is the overload preference rule for more specific concepts. 1\. Nope, the is operator is superior. I can cite several reasons: a) It's more consistent and friendlier to refactoring (then you change a concrete type to a inferred type, you don't have to modify anything else on the line) b) the type assignment proposal is less capable and ultimately incomplete. Most of the inferences will happen when the types appear in a param position in a proc call (e.g. such as `s.push(T)`). Or the inferred type may appear as a generic param of another type (e.g. `x.foo is seq[T]`). Both of these are not encodable with the assignment approach. c) the assignment already has a well-defined meaning within the concept. It's used to test for the presence of an assignment operator 2\. This is not a problem. The binding of generic params work by their internal assigned numeric IDs (not by their names). 3\. I have explained how this works in the manual. 4, In my example, K is inferred as evident in the compiler output here: [https://github.com/nim-lang/Nim/blob/generic-concepts/tests/concepts/tmapconcept.nim#L7](https://github.com/nim-lang/Nim/blob/generic-concepts/tests/concepts/tmapconcept.nim#L7) I'm not sure what you meant to ask in the second question, but it's not possible for an object to match both Map[int, int] and Map[float, string]. BTW, I added valuesSeq() just because I wanted to test the use of nested parametric concepts (see how Enumerable[T] is using an inferred type). A real Map concept will probably look for keys and values iterators.
