wrong isInputRange design

[Jonathan M Davis via Digitalmars-d]

On Sunday, December 04, 2016 13:37:35 rumbu via Digitalmars-d wrote:
> I think that the array range UFCSs must be moved out from the
> std.range.primitives and let the library user to decide if there
> is a need for range semantics applied to all arrays.

That's not happening. In fact, pretty much the only reason that the array
range primitives haven't been moved to object.d is because of the
auto-decoding issues with strings and the fact that the auto-decoding relies
on std.utf in Phobos, whereas object.d is in druntime, which doesn't have
access to Phobos. The fact that we currently have to import std.range or
std.range.primitives to get arrays to behave properly as ranges is an
annoyance that we want to fix, not something that we want to solidify.  And
other modules - such as std.algorithm - actually publicly import std.range
in an attempt to reduce the amount of importing pain with the range
primitives. Ranges are a core part of D, and it was never really intended
for the range primitives to be optional. They just didn't need to be put
into the language or druntime to work, so Andrei put them in Phobos. There
are some minor changes that were made to the language (e.g. foreach knowing
about the input range primitives), but overall, the range stuff was done via
the standard library, because there was no need to do it with the language,
and Andrei favors doing stuff with the standard library where possible
rather than doing it with the language.

So, really, the intention here is that all range based code imports the
range primitives for arrays, and there is no plan to support the range-based
stuff without them. And there was recently talk of putting the array range
primitives in object.d in spite of the auto-decoding mess and just putting
more of the std.utf stuff in druntime. So, if anything, that's the direction
that things are going, not towards trying to make it possible for code to
use isInputRange sanely without the array primitives. The only reason that
you're even hitting this issue is because you're explicitly avoiding
importing all of the range primitives together and are trying to grab
certain ones individually, which was never an intended use case. So, if
you're doing that and running into problems, I'm sorry, but you're trying to
use the library in a way that it was not designed to be used.

- Jonathan M Davis