http://d.puremagic.com/issues/show_bug.cgi?id=10762

           Summary: std.range.iota should support any type that has
                    ordered comparisons, incrementing, and addition
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: hsteoh@quickfur.ath.cx


--- Comment #0 from hsteoh@quickfur.ath.cx 2013-08-05 12:01:50 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10762


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10762



--- Comment #1 from hsteoh@quickfur.ath.cx 2013-08-05 12:04:55 PDT ---
Basically, any type that comparable by "<", supports "++" or addition with the increment type, should work with iota.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10762


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com


--- Comment #2 from monarchdodra@gmail.com 2013-08-05 12:20:56 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10762


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #3 from bearophile_hugs@eml.cc 2013-08-05 12:34:51 PDT ---
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)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10762



--- Comment #4 from hsteoh@quickfur.ath.cx 2013-08-05 13:41:39 PDT ---
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)?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10762



--- Comment #5 from monarchdodra@gmail.com 2013-08-06 03:41:22 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------