On Monday, 24 August 2015 at 17:17:16 UTC, Steven Schveighoffer
wrote:
3) it is not possible to "ask" a range if it's empty more
times per
iteration of one item
This isn't very composable. If I call a function that consumes
some number of items from a range, that function needs to
forward the information back to me of whether the range is now
empty or not.
That is a very good point. Non-existence of 'empty' property
would have negative impact on composability and convenience of
use if range is shared between alogorithms (For example in a
parser). As you say that information would need to be transferred
in program using another means. I see this composability aspect
as critical, and for me it alone makes 100% case for the
existence of 'empty' property.
4) it does _not_ requires range to be in "ready" state
immediately after
construction. That means that popFront needs to be called
firstly,
before front can be. This I feel is biggest change. Since D
ranges are
required to have front ready immediately after their
construction. Which
for some non trivial ranges can seem as less
effective/convenient/expected.
So on the flip side, ranges that *could* be ready as soon as
they are created, must store some state that says popFront
hasn't yet been called. I find this requirement to be a wash
implementation-wise, and actually a negative API wise, since
you as the consumer of the range must carry the burden of
storing whether it was empty the last time popFront was called.
I would challenge you to write a wrapper for an array slice
(yes, you would need a wrapper, not just simple UFCS functions)
and see whether you think it's still worth it.
-Steve
Ok. What about this: there exactly the same 3 primitives as in D
range, but popFront is requred to be called first, before calling
front, or empty properties. Why current approach against this?
