On Tuesday, 13 July 2010 at 03:48:08 UTC, Andrei Alexandrescu
wrote:
I think I figured out a comfortable and all-encompassing means
to define a simplified interface for an input range.
Currently input ranges need to define empty, front, and
popFront. That works but it's a bit heavy for simple input
ranges. We've been discussing simplified interfaces in this
group but couldn't find one that satisfied all use cases.
This feels quite similar to "consumeFront"? As a matter of fact,
isn't it just exchanging:
"Check Not Empty" then "consumeFront"
for
"getNext" then "checkNotNull"
Semantics: if the range wants to expose addresses of its
elements, it returns a pointer to the current element and also
advances to the next element. Otherwise (i.e. the range does not
have or does not want to expose addresses of its elements), the
range fills "item" with the current value, again moves on to the
next value, and returns &item.
My big worry here is that when the range does _not_ want to
provide a pointer to its internals, the caller has no way of
knowing it. Modifying the pointed object may or may not modify
the range.
For example, "std.algorithm.map" on an Array!bool simply can't
work with getNext. Since the implementer has no idea what he is
operating on, the conclusion is that he simply can't use getNext
when mutation is possible.