On 7/9/12 3:03 PM, Mehrdad wrote:
Sure, we all agree that a multi-pass range is also a one-pass range. I don't have a problem with that. But if you only use the one-pass range aspect, that doesn't mean it has to use the same syntax as the multi-pass range aspect.
But that works against your goal of simplifying things.
The issue is, while you are /telling/ me that "input range" is a misnomer, that doesn't match what Phobos's is telling me. In Phobos, you've placed a very clear difference between "input ranges" and "output ranges", and /both/ of them are single-pass.
An output range only needs put(). In that sense it's an endless bag in which you get to put stuff without any control over e.g. navigation. A one-pass range may or may not accept assignment to .front. In particular, put() is written to detect and use that. And that's about it.
It looks like it was deliberately designed that way... I don't think you made a mistake when separating input and output ranges like that (unless you do?).
I sense a Jedi trick is tried unto me.
So unless you're planning on trashing all that and redesigning the entire thing from scratch (are you?) I don't understand how you can have two orthogonal bases for working with ranges like this.
I agree with your assessment that you don't have a good understanding of how D ranges work. Nevertheless, proposing an alternative design would be a great basis for discussion; isolated fragments of designs look attractive in isolation but often fail to offer the whole picture.
Andrei