For example, iota should work with Date: auto r = iota(Date(2013,1,1), Date(2014,1,1), dur!"days"(1)); Currently, this is not supported.
Basically, any type that comparable by "<", supports "++" or addition with the increment type, should work with iota.
Related: [Issue 6447] New: iota(BigInt) too http://d.puremagic.com/issues/show_bug.cgi?id=6447 AFAIK, the only difficulty with making this work is that the return type is currently "CommonType!(Beg, End, Step)". Whereas it should be more like something along the lines of: typeof(CommonType!(Beg, End).init += Step.init); But nothing too difficult to integrate anyways.
Elsewhere there was a discussion for: iota!"[]"('a', 'z') iota!"[]"(ubyte.min, ubyte.max) Should enums too be supported? enum MyE { A=1, B=15, C=6, D=9, E=22, F=3 } iota(MyE.B, MyE.E)
There are other considerations as well. Let's say we are calling iota(start,end,inc). Let S=typeof(start), E=typeof(end), I=typeof(inc), C=CommonType!(S,E). Then: 1) Ideally, as long as C.init<end is a valid expression, and start+inc is convertible to type C, then iota(start,end,inc) should be supported. 2) Should we optimize iota(start,end,inc) in the case that I supports integer multiplication? That is to say, if n is an integer, and n*inc (or inc*n) is a type that can be added to values of type C, then we could potentially return a random access range wherein opIndex returns start + i*inc as long as the result < end (we can throw a RangeError if result !< end). This might be a nice optimization for things like BigInt in some cases. 3) If start+inc is *not* supported, but start++ is, then should we support iota(start,end)? 4) If start+inc is *not* supported but start-- is, and end < start, should we support iota(start,end)?
(In reply to comment #4) > 2) Should we optimize iota(start,end,inc) in the case that I supports integer > multiplication? That is to say, if n is an integer, and n*inc (or inc*n) is a > type that can be added to values of type C, then we could potentially return a > random access range wherein opIndex returns start + i*inc as long as the result > < end (we can throw a RangeError if result !< end). This might be a nice > optimization for things like BigInt in some cases. I think providing RA is possible, but at the same time, I doubt there is much usecase for it. iota's prime usecase is iteration I mean. If we can make it happen, then great I guess, but I don't really see it as essential. > 3) If start+inc is *not* supported, but start++ is, then should we support > iota(start,end)? > > 4) If start+inc is *not* supported but start-- is, and end < start, should we > support iota(start,end)? I think that for "iota(end)/iota(start, end)", the constraint should be that "++"/"--" works. For "iota(start, end, step)", then the constraint should be "+=". So I to answer your question, I think that "Yes", we should support iota(start, end) as soon as ++/-- is available.
https://github.com/D-Programming-Language/phobos/pull/2895
Related: https://issues.dlang.org/show_bug.cgi?id=6447
Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b159a5bdc980abb90833b32fa04044a002dfc794 Merge pull request #2895 from quickfur/iota_bigint Issue 6447 & 10762: support user-defined types in iota()
Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b159a5bdc980abb90833b32fa04044a002dfc794 Merge pull request #2895 from quickfur/iota_bigint