On Thu, 27 Mar 2014 17:28:05 -0400, Walter Bright
<[email protected]> wrote:
On 3/27/2014 1:59 PM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 16:53:35 -0400, Walter Bright
<[email protected]>
wrote:
On 3/27/2014 9:12 AM, monarch_dodra wrote:
If you initialized the next element in both constructor
As mentioned earlier, requiring this of a range constructor makes it
impossible to separate composition of a range with using it.
Not impossible. Use lazy initialization.
That still doesn't work, because then you could be calling front, and
front might fail if there's no input.
In the cases where you know there is input, that's not true. What I am
protesting is the idea that you *know* input exists, you must still call
empty. Front is enough in that case.
What is wrong with following the protocol? Why must we introduce all
these caveats for ranges, like streams not working, front that can fail,
can't do C# style LINQ, etc.? For what gain?
There is no gain to requiring empty on ranges where you logically prove
they are not empty. It's a wasted call. For things where you're not sure
if they are empty or not (e.g. an input file), of course empty is required
to be called, and of course it may do some processing to determine that.
But I would only expect that on the first call. Subsequent checks would
already be done by popFront.
It only makes sense if you are using empty in your processing of the
range.
I.e. follow the danged protocol and it works.
I mean, if you are calling empty regularly, because you aren't sure
whether the elements are there. That's not always the case, sometimes you
are sure the elements are there. Requiring a call to empty to do anything
other than to check whether a range is empty, is just plain wrong. I'm
sure there's better ways to implement what you want without stitching the
functionality onto empty.
-Steve
