On Friday, 12 February 2016 at 19:20:29 UTC, Andrei Alexandrescu wrote:
> On 02/12/2016 02:18 PM, Meta wrote:
>> On Friday, 12 February 2016 at 19:00:29 UTC, Andrei Alexandrescu wrote:
>>> Tried that for a while, it quickly became a mess of entangled
>>> intestines. Not worth it. -- Andrei
>>
>> What do you think of the solution I proposed above? It's not pretty but
>> there has to be some kind of workaround. Not being able to use
>> `parallel` with an iota-range of ulongs on 32-bit DMD is not good. If
>> you will pre-approve it (comments/suggestions optional) I can submit a
>> PR within the next day or so.
>
> I'd be more partial to an additional template parameter. Or even change the type of length in certain cases. -- Andrei

Okay, I will look into other solutions and post some options soon.

Maybe I'm missing something, but can't the length just be size_t? I doubt there is much you could do with code which generates finite sequences larger than the addressable memory space, aside from very abstract and inefficient mathematical calculations which skip over elements. iota would probably work better with size_t in most cases, and if you really well and truly need something which generates finite sequences of integers larger than the addressable memory space, you can always just write your own version.

On Sunday, 14 February 2016 at 10:59:41 UTC, w0rp wrote:
> Maybe I'm missing something, but can't the length just be size_t? I doubt there is much you could do with code which generates finite sequences larger than the addressable memory space, aside from very abstract and inefficient mathematical calculations which skip over elements. iota would probably work better with size_t in most cases, and if you really well and truly need something which generates finite sequences of integers larger than the addressable memory space, you can always just write your own version.

Yeah. It would be easy enough to just make iota size_t and then have it check the actual length of the range when it's called to make sure that it's not larger than will fit in size_t (and presumably throw a RangeError if the number of elements is too large). Anyone who really wants to have a range with more than size_t.max elements can write their own thing. It's not like it's going to work nicely with other ranges anyway - at least not as long as it defines length.

- Jonathan M Davis

On Sunday, 14 February 2016 at 13:16:58 UTC, Jonathan M Davis wrote:
> On Sunday, 14 February 2016 at 10:59:41 UTC, w0rp wrote:
>> Maybe I'm missing something, but can't the length just be size_t? I doubt there is much you could do with code which generates finite sequences larger than the addressable memory space, aside from very abstract and inefficient mathematical calculations which skip over elements. iota would probably work better with size_t in most cases, and if you really well and truly need something which generates finite sequences of integers larger than the addressable memory space, you can always just write your own version.
>
> Yeah. It would be easy enough to just make iota size_t and then have it check the actual length of the range when it's called to make sure that it's not larger than will fit in size_t (and presumably throw a RangeError if the number of elements is too large). Anyone who really wants to have a range with more than size_t.max elements can write their own thing. It's not like it's going to work nicely with other ranges anyway - at least not as long as it defines length.
>
> - Jonathan M Davis

+1

On Friday, 12 February 2016 at 05:51:34 UTC, Meta wrote:
> If you try to compile this code, it will currently not work:
>
> foreach (n; iota(1UL, 1000).parallel)
> {
>     //...
> }
>
>
> This is because of how the length is calculated by iota:
>
> auto iota(B, E)(B begin, E end)
> if (isIntegral!(CommonType!(B, E)) || isPointer!(CommonType!(B, E)))
> {
>     import std.conv : unsigned;
>
>     //...
>
>     //The return type of length. When either begin or end
>     //is ulong, then IndexType == ulong
>     alias IndexType = typeof(unsigned(end - begin));
>
>     static struct Result
>     {
>         private Value current, pastLast;
>
>         //...
>
>         @property IndexType length() const
>         {
>             return unsigned(pastLast - current);
>         }
>     }
>
>     return Result(begin, end);
> }
>
>
> And because std.parallelism.TaskPool.defaultWorkUnitSize takes a size_t, which with a 32-bit DMD is uint.
>
> What I want to know is, is this considered a bug? If so I will submit a pull request to fix it.

I made a pull request: https://github.com/D-Programming-Language/phobos/pull/4013