All right, I didn't know about this. So a metatype is really a metatype, it can
be a set of types, and not just one type. Ok. As long as we are intersecting
sets of types, nothing wrong can happen. Rereading your example
type
MyConcept = concept x
type T1 = auto
x.foo(T1)
x.bar(T1) # both procs must accept the same type
the comment maybe should be "both procs have versions which accepts the same
type" (yes, I'm a Mathematician).
Let me bring up some cases. Most probably the world won't end if these are not
working properly, but let's have some chat about them.
I always dreamed about two iterable concepts, one with size, and one without
size (when the size is known, we can preallocate in `map`). I understand that
with _Concept refinement_ this is doable, but let's assume that I want to write
my own two types. This is the one without size:
type IterableWithoutSize[V] = concept c
c.items() is V
not compiles(c.size())
Will this work?
Now let's assume that we have a concept for stacks which are not hashable (the
motivation is very similar, let's assume that we can do some magic by hashing
the values, so more efficient code can run):
type StackNotHashable[V] = concept c
c.push(T)
c.pop(var T) is bool
not compiles(hash(T))
If your object supports more than one `Stack[T]` (e.g., `Stack[int]` and
`Stack[myNotHashableType]`), then would it be able to infer `T` to
`myNotHashableType`?
Moving forward, if I want to make a concept where the keys and values are
comperable (for example to count how many values are greater than their keys),
then:
type MapComperable[K,v] = concept c
c[K] = V
K < V
Let's assume that I have a type which is `Map[int, long]` and `Map[string,
float]`. Is it going to match and infer `MapComperable[int, long]`? Or is the
compiler get confused about the fact that `int` can be compared by `float`
(from the other pair), when it thinks that `K = int|string` and `V =
float|long`?
