I'm still not a big fan of storing a list generics for types (like `T=char` for
`string`). Let me show an example which I think should compile:
type HasValues[T] = concept c
T = type(c.values()[0]) # maybe an iterator check would be more
appropriate, let me be sloppy here
proc sumOfValues[T](m: HasValues[T]): T =
for x in m.values():
result += x
You could call `sumOfValues` with `Map[K,V]`, also with `Set[V]`, because both
of these have `values()`. I don't see how this could be done with the fixed
generics list proposed above elegantly (without having `Set[Dummy, V]` mapping).
We still think about a basic container types, but a complex object could
implement several concepts with different types.
The problem is what `T` means in a concept. There are 2 good place to define
this: when we define the type (like in Java with `implements`) or when we
define the concept (for example in the concept's body with `T =
type(c.values()[0])`). I don't think that this should be somewhere else with
`declare`, because that would mean that there can be 3 separate places in code
which effects the behavior. The possibility that we can export these rules
looks even more problematic. In Rust you can implement a trait only in two
packages: where the trait or the type is implemented. I think that we should
follow that logic. (In Scala your code can run differently if you add one extra
import, I've heard people complaining about this.)
I really try not to be rude in my posts, no offense was intended.
Peter
