On Thu, 27 Mar 2014 19:52:52 -0400, Walter Bright
<[email protected]> wrote:
On 3/27/2014 2:46 PM, Steven Schveighoffer wrote:
What I am protesting is the idea that you *know* input exists, you must
still call empty.
Front is enough in that case.
You can't use that on generic code, because generic code cannot assume
that front will not fail.
There is a difference here that I want to establish.
First, I completely agree that for generic code, for when an unknown range
is passed in, empty is required to be called to verify that front is valid.
Second, while I agree that empty should be required to verify front is
valid on unknown ranges, it should not be required, when it is known that
it's not empty.
What you are proposing is that we take advantage of the requirement for
empty on unknown ranges to require it on known ones. I disagree, the code
looks awkward and incorrect. When I know something is empty, calling empty
again doesn't give me information. instead empty now becomes "is it empty,
and if it needs priming, prime it." I'd rather see another primitive,
since empty does not convey that message.
A counter proposal -- What if we create a global method in std.range
called prime. prime(r) will call r.prime if it exists, otherwise calls
r.empty, and ignores the result. Code that wants to work with "primable"
ranges, can call that function, and it's harmless for normal ranges, but
will allow primable ranges to fetch the first element.
I think penalizing all range-using code to force a non-functional empty
call would 1. artificially invalidate lots of currently valid code and 2.
look completely awkward in cases where it's not normally necessary.
-Steve
