type Iterable = generic i
i.items is iterator
# Ascertain the element type of some iterable type.
template Element(I: typedesc): typedesc =
var i: I; i.items.type
# Ascertain the element type of some iterable value.
template Element(i: Iterable): typedesc =
i.type.Element
# Try to query the element type of a sequence of integers.
# This fails because the compiler isn't sure which template to use.
type E = seq[int].ElementIs this behavior desired or expected? It seems a little confusing.
Is it related to the fact that types can be passed into templates as expression arguments (also a little strange to me)?
I'd love to see a working generic in the near future--I make heavy use of it in my lazy collections/grids library (think D's ranges mixed with NumPy) and it would be great to be able to share my work as a fully-supported package. However, I have run into (and reported) a number of issues with it.
As for removing generic from 1.0, from my perspective,
Maybe the best solution: release 1.0 without generic [1], but have a section in the manual that says "It's on it's way, and here's exactly how it works".
[1] Or whatever it will be called; I think I saw a discussion on Github about renaming it.
I think feature gating of buggy features is the right decision at this stage. Having stuff "just work" will be important when 1.0 comes out, so focus on that minimum viable product.
Having said that, the polymorphism of Nim's user defined type classes looks quite useful, so I hope it gets some love post 1.0. Will it be removed from the manual, or is the expectation that the implementation just needs bug fixing?
Having just seen Mason McGill's post, I would also think that perhaps renaming this feature to 'trait' from 'generic' would be a good idea, since in Nim genericity is used to describe Nim's approach to parametric polymorphism. 'concept' from C++ would also work.