Bug 10762 – std.range.iota should support any type that has ordered comparisons, incrementing, and addition
Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-08-05T12:01:50Z
Last change time
2017-08-31T11:48:00Z
Keywords
pull
Assigned to
No Owner
Creator
hsteoh
Comments
Comment #0 by hsteoh — 2013-08-05T12:01:50Z
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.
Comment #1 by hsteoh — 2013-08-05T12:04:55Z
Basically, any type that comparable by "<", supports "++" or addition with the increment type, should work with iota.
Comment #2 by monarchdodra — 2013-08-05T12:20:56Z
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.
Comment #3 by bearophile_hugs — 2013-08-05T12:34:51Z
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)
Comment #4 by hsteoh — 2013-08-05T13:41:39Z
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)?
Comment #5 by monarchdodra — 2013-08-06T03:41:22Z
(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.