Bug 3000 – iota should work with floats

import std.range; void main() { auto foo = iota(0.0L, 10.0L, 1.0L); } The above doesn't compile and results in a bunch of long errors that aren't particularly useful for diagnosing the cause of the problem. The real problem is line 2089, range.d: return take((end - begin + step - 1) / step, Seq(tuple(begin, step), 0u)); The problem is that, if the arguments to iota are floats, not ints, the number of elements take() is told to take is a float, not an int. This can be fixed trivially by changing that line to: return take(cast(size_t) ((end - begin + step - 1) / step), Seq(tuple(begin, step), 0u)); Also, take() should probably use a ulong, not a size_t. I could picture someone wanting to run a long monte carlo simulation, for example, by taking more than 4 billion elements from an infinite range of random numbers.

Fixed in future 2.032 (and checked in for the impatient).

Should the examples be updated to include one for floats, maybe? Also, how about adding a bit more sanity checking such as B, E, and S are all numeric types? Also, what does 'iota' stand for? I keep reading it as 'itoa' which is obviously wrong.

(In reply to comment #2) > Should the examples be updated to include one for floats, maybe? Done. Also found and fixed a couple of issues with negative ranges. > Also, how about adding a bit more sanity checking such as B, E, and S are all > numeric types? B and E can be pointers. I did add a check that should eliminate nonsensical calls. > Also, what does 'iota' stand for? I keep reading it as 'itoa' which is > obviously wrong. It's an actual word of which meaning in the current context I borrowed from some STL implementations (http://www.sgi.com/tech/stl/iota.html). Bug fixed and checked in; the fix will come in dmd 2.032.

I thought that might be the case (regarding the name), but it wasn't obvious. And I still keep reading it with the o and t reversed. :) Thanks for the updates.