Thanks for the explanation. I know about the more-specific overload process
(however, I never (ab)used it), and also the _Concept refinement_ in your
proposed manual looked like something useful in this case.
Yes, this looks hypothetical here. However, I think that we should prepare for
people who are not familiar with the compiler's logic. If this is finalized in
this form, then I'll vote for a Map concept where types are clearly inferred at
the beginning, e.g.,:
type Map[K,V] = concept c #and following your notation, var m, etc.
c.keys()[0] is K # first line
c.values()[0] is V # second line, or a check with "for" cycle to support
iterators as well
... # rest of the concept after K and V inferred
just to avoid any possible bugs in the future.
Let me go back to the last example, let's assume that only `int < int` makes
sense (so `int<string`, `string<string` and `string<int` are not implemented).
My problem here is that the compiler will infer `K` to `int` and `V` to `int`,
which is a serious mistake, because my type clearly doesn't match
`MapComperable[int,int]`. So in this case my type would match this:
proc f[K,V](x: MapComperable[K,V]) = discard # here K=int and V=int
f(myX) # runs incorrectly
but won't match (correctly) this:
proc f(x: MapComperable[int,int]) = discard
f(myX) #fails correctly
The life would be much easier if we weren't supporting function argument match
in concept, and we would limit inferring only to the `is` magic operator.
