getNext
Mehrdad
wfunction at hotmail.com
Mon Jul 9 12:30:27 PDT 2012
On Monday, 9 July 2012 at 19:22:39 UTC, Andrei Alexandrescu wrote:
> But that works against your goal of simplifying things.
If by "simplification" you mean "fewer methods to call", then yes.
If by "simplification" you mean "easier to understand", then no
-- not here.
Having a different (but still simple) syntax for a more capable
range is far better than the getNext() proposal here.
> I sense a Jedi trick is tried unto me.
lol wasn't intending to, but whatever.
> 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.
> I agree with your assessment that you don't have a good
> understanding of how D ranges work.
I certainly don't have a good understanding of how they were
_intended_ to work, is what I found out in this thread. The docs
(or even the names, as you mentioned yourself) don't at all
convey what you guys explained here, so if they were designed one
way but intended to work another way, then /of course/ I don't
have a good understanding of how they were intended to 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.
I agree. My alternative would be to abandon similar 'hasXYZ'
stuff (which doesn't convey the picture and looks hacky), and
instead formally define what those are, like I/O range. Sounds
good/bad?
More information about the Digitalmars-d
mailing list