Bug 15687 – isInputRange/isForwardRange discriminate against void[]

I tried using `chunks(data, size)` when data was const(void)[], but it didn't work. When I changed it to const(ubyte)[] everything was OK. It boils down to the fact that pragma(msg, isInputRange!(void[])); // false pragma(msg, isInputRange!(ubyte[])); // true which uses template isInputRange(R) { R r = R.init; r.popFront(); } which guards against it: std.range.primitives.popFront(T)(ref T[] a) if (!isNarrowString!(T[]) && !is(T[] == void[])) I'm not sure if it's a bug or not, but I think chunks(void[]) ought to work as it returns `void[]`, not `void`

I think the main reason is that void[] cannot have valid `front` property as a Range. In std.range.primitive: @property ref T front(T)(T[] a) @safe pure nothrow @nogc if (!isNarrowString!(T[]) && !is(T[] == void[])) { ... } @property dchar front(T)(T[] a) @safe pure if (isNarrowString!(T[])) { ... } The template constraint of `popFront` would just follow the `front`'s.

Well, while I can see why some range-based functions might conceptually work with void[], they won't in general, because of the issue with not being able to have a valid front. So, I'm very much inclined to argue that this is not a bug and that it's just life with ranges. To do otherwise would require either special casing void[] with some functions or creating a new kind of range concept that can be iterated over but not examined - and thus has popFront and empty but not front - and I don't think that that's worth it. Casting to const(ubyte)[] should work just fine, and if you really don't want to do that, you can create a wrapper range with whatever you want for the element type and which has assert(0) in front to make sure that it's not called - and then presumably converts nicely to void[] after you've iterated however much you want to iterate.

Closing as invalid due to lack of counter arguments.