On 3/26/2014 7:19 PM, Steven Schveighoffer wrote:
if(!r.empty)
{
auto r2 = map!(x => x * 2)(r);
do
{
auto x = r2.front;
...
} while(!r2.empty);
}
Should we be required to re-verify that r2 is not empty before using it? It
clearly is not, and would be an artificial requirement (one that map likely
would not enforce!).
This sounds so much like a convention that simply won't be followed, and the
result will be perfectly valid code.
The idea is that there are three functions: empty, front, and popFront. The
functionality of the range will be distributed between these 3 functions.
Different things being ranged over will naturally split their operations into
the 3 functions in different ways.
If the 3 functions can be called in any order, then extra logic has to be added
to them to signal to each other. This slows things down.
To write generic code calling ranges, it's necessary to stop assuming what is
happening under the hood of empty, front, and popFront, and stick to the protocol.