On Thursday, 24 October 2013 at 17:52:45 UTC, Jonathan M Davis
wrote:
On Thursday, October 24, 2013 17:55:22 Chris wrote:
On Thursday, 24 October 2013 at 15:40:22 UTC, Dicebot wrote:
> On Thursday, 24 October 2013 at 15:36:59 UTC, Chris wrote:
>> How do you define side effects? After all ranges manipulate,
>> reformat or restructure data.
>
> They should do it in popFront. I'd consider any `front` that
> does anything but accessing cached value suspicious.
So code like
auto front() {
doSomething();
return range[0];
}
should go into
void popFront() {
doSomething();
range = range[1..$];
}
Yes. front _will_ be called multiple times by many range-based
algorithms.
There are no guarantees whatsoever that front will not be
called more than
once and relying on it being called only once between calls to
popFront is
just plain wrong.
front is the logical equivalent to a public member variable and
should be
treated as such. In general, putting additional work inside of
front is just
asking for trouble. And if you do, it needs to be with the
understanding
that front stands a good chance of being called multiple times
per call to
popFront.
It might make sense to add some debug stuff in there which has
side effects
(like printing something out), but the code's normal semantics
should not
rely on any kind of side effects on front. There should be no
logical
difference if you call front one time or twenty times after a
single call to
popFront.
- Jonathan M Davis
Well, I just had a weird bug due to some stuff being in front. I
moved everything into popFront and it worked as expected.
It was a linked list where PREVIOUS and CURRENT are checked and
changed if certain conditions are met. Suddenly I got weird
behaviour and PREVIOUS and CURRENT where the other way around or
an old PREVIOUS showed up later. I guess I've learned my lesson.
