On Tuesday, 3 July 2012 at 17:40:24 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which
invalidates their
front value when popFront is called, for instance,
File.byLine. Thus
takeFront will have to be used with care: any range implement
takeFront
(because of the template and USFC), but it may not be valid.
That makes
the range interface more complicated: There is a takeFront
property, but
you have to check it is safe to use... how do you check that
by the way?
Hmm. I hadn't thought of that. That could be a good reason not
to do this. I'm
not quite sure how to get around that. Hmmm... It would
arguably be a bit
ugly, but a range which couldn't safely be used with takeFront
could have an
enum on it which indicated that, and takeFront would fail to
compile if used
with such a range. Of course, that would mean that you'd have
to special case
such ranges in any range-based function which used takeFront so
that there was
a branch which didn't use takeFront for ranges which couldn't
use it.
I don't know. It's certainly something to think about. We may
need a different
solution.
An alternative is not to define a free function. So if
consumeFront is defined, it may be used by the algorithm,
otherwise simply call to front and popFront in the algorithm. If
branching is necessary, then the is no value in a free function
(it wouldn't optimize for speed any way).
