www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10762] New: std.range.iota should support any type that has ordered comparisons, incrementing, and addition

reply d-bugmail puremagic.com writes:
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



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: -------
Aug 05 2013
next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10762




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: -------
Aug 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10762


monarchdodra gmail.com changed:

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



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: -------
Aug 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10762


bearophile_hugs eml.cc changed:

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



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: -------
Aug 05 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10762




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: -------
Aug 05 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10762






 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: -------
Aug 06 2013