Hi,
I'm playing with the idea of creating a generic container. What is the current state of concept[T]? For simplicity, let's assume that I would like to create a Map type just in Java (just for this example, I really want something cooler than Map). The Map in Java is an interface, which has several implementations: HashMap, TreeMap, etc. Could I define a concept for Map with type T and require some procs (like hasKey, etc.)? If not, then is there any info about this issue's priority? Are there any workarounds?
(I could mention Rust's iter library instead of Java's Map, they have some traits which works like Java's interface: https://github.com/rust-lang/rust/blob/master/src/libcore/iter.rs)
The subject line is a little misleading. As far as concepts are concerned, they are pretty robust now. Araq checked in a ton of fixes in the past few weeks. I use them extensively, and I have not found any issues other than the few remaining on the GitHub issues list.
Now, as for your real question about how to model containers for polymorphic types in Nim, I do not know. From what I understand, concepts are almost certainly not the right tool for that. Concepts are not like interfaces in C# or Java, but more like type classes in Haskell that define a contract that a type has to fulfill in order to be able to constrain generics, not necessarily a particular layout of its procedures in memory (i.e. as a virtual function table). I don't see how one would be able to store concept-like things in some container, other than reverting to some kind of run-time type information system that dynamically attempts to resolve fields and procs on a particular instance.
I think that the matter of polymorphic containers has been discussed previously on this forum. You might be able to find some more details with a forum search, and I don't think that there have been any news since. I have not put much thought into this, and others can probably give a much better answer, but my gut feeling is that polymorphic containers might be symptomatic of object-oriented programming, and there may be better ways to solve the problems that they were designed for. One technique that I recently learned are tuples of closures, and I'm still in the process of exploring how they can be used most effectively.