Re: [boost] [move] [range] move algorithm (was: interest: the pass-by-value...)

Subject: Re: [boost] [move] [range] move algorithm (was: interest: the pass-by-value...)
From: Neil Groves (neil_at_[hidden])
Date: 2014-02-18 13:30:36

On Tue, Feb 18, 2014 at 5:32 PM, Eric Niebler <eniebler_at_[hidden]> wrote:

> On 02/18/2014 09:16 AM, Adam Wulkiewicz wrote:
> > Hi Eric,
> >
> > Eric Niebler wrote:
> >> On 02/15/2014 02:17 PM, Adam Wulkiewicz wrote:
> >>> There is already boost::move_iterator in Boost.Move
> >> Please make sure that move iterators and ranges are Input and not
> >> anything else, regardless of what the standard says. The standard is
> >> dangerously wrong in this regard.
> >
> > Thanks for the advice. It's because the user might by mistake go through
> > some elements more than once which would result in some number of moves
> > from the same element or do you have something more surprising in mind?
>
> That's it precisely. And using move iterators in standard algorithms
> that assume anything other than Input is pretty much guaranteed to make
> you very unhappy.
>

I agree that many scenarios would end in much unhappiness! I disagree that
unhappiness is pretty much guaranteed. I believe there are valid scenarios
that would be broken by increasing the requirements to demand single-pass
traversal. The most common case that I think would be broken in my own code
is where I am using a random-access iterator to stride. Currently I can
stride and move ever n-th element. Isn't this perfectly acceptable? I'm not
convinced we should break any valid use-cases to detect more errors.
Perhaps we can find a better mechanism to detect double moves in debug
builds instead?

>
> > Unfortunately the boost::move_iterator follows the standard here. And
> > since it's already in Boost it probably shouldn't be changed to ensure
> > backward compatibility. We could of course implement different one and
> > use it in Boost.Range but I'm not sure if this is a good idea. Should we
> > have two different move_iterators in Boost?
>
> I take a hard stand on this. A Forward move iterator is totally broken.
> I have *no* sympathy for people who are using move iterators where
> Forward is needed. Their code is buggy. We should change
> boost::move_iterator and help people find their bugs. I have zero
> compunction about doing this.
>
>
If my previous paragraph is correct I believe we should not break working
user code. Under my current understanding I don't think multiple (and
therefore invalid) moves should be prevented by increasing the limits of
the traversal. I think that the problem is a multiple moves and this can
and should be dealt with directly instead. I wonder if the standard is
liberal in the traversal requirements for similar reasons?

> Eric
>
>
I'm conscious that I could easily be misunderstanding some information and
therefore my chain of reasoning may be broken.

Neil Groves