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
