On Wednesday, July 12, 2017 at 2:53:19 AM UTC-7, d...@soun= dradix.com wrote:

Hi,

Would anyone be interested in adding std::shift = to <algorithm>?=C2=A0

It would be similar to= both:
- std::rotate, but without moving the head elements back t= o the tail. This would allow a more efficient implementation and clearer se= mantics in case rotation is not needed as well as correctness in case rotat= ion is undesired.
- <algorithm>'s std::move/std::move_b= ackward (depending on the shift direction).

std::s= hift should probably accommodate both left and right shifts by one of:
- giving it either begin() and end(), or rbegin() and rend(), similar= to how std::rotate works for both left and right rotations. The advantage = is compactness of the implementation.
- allowing the shift count = parameter to be either positive or negative. The advantage is compactness, = though it might not be clear which direction is which - to be consistent wi= th rotate, positive integers should shift to the left.
-= having std::shift_right and std::shift_left functions. The advantage is cl= arity when calling the methods, although the same argument could be made fo= r having separate std::rotate_left and std::rotate_right instead of std::ro= tate, which we don't have.

std::rotate is actually just a rotation; it doesn't need "le= ft" or "right" qualification because they're 100% equiva= lent. Consider a classroom globe with London in front, facing you. Now &quo= t;rotate" the globe until Beijing is in front. It doesn't matter i= f you rotate left or rotate right; the outcome is exactly the same either w= ay.

=C2=A0

Here's a sample implementation of a shift to the righ= t direction:

template<class BidirIt><= span style=3D"color:#000"> void shift_right(= BidirIt= first,= BidirIt last,= unsign= ed int<= /span> n =3D 1= ) <= span style=3D"color:#660">{ =C2=A0 = =C2=A0 std::move_backward(first, last - n,= last);= }<= /span>

This demonstrates that while std::shift is implementable with std::= move/std::move_backward,
1) It isn't immediately clear from t= he code (at least to my eyes) that this is a shift right, unless you are in= timately familiar with std::move_backward.
2) Different calls, ei= ther to std::move or to std::move_backward, are required, depending on the = shift direction.

If you're = shifting the whole container's contents, you could use either of these:=

=C2=A0 =C2=A0 std::move(ctr.rbegin() + n, ctr.rend(), ctr.rbegin= ());

=C2=A0 =C2=A0 std::move_backward(ctr.begin(), ctr.end() - n,= ctr.end())?

I don't currently see the use-case for this &quo= t;shift just a piece of a container" algorithm, I mean as distinct fro= m std::move and std::move_backward which already exist. Do you have a use-c= ase?

Re naming, notice in passing that std::valarr= ay::shift() exists, and std::left_shift<T> and std::right_shift<T&= gt; do not exist but obviously should. The name std::shift it= self is indeed still available. I question whether it should be used for th= is purpose, though.

=E2=80=93Arthur

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/68bbd6d3-1578-43e1-b15f-563c9d6fb27c= %40isocpp.org.
------=_Part_139_914765861.1499903224956-- ------=_Part_138_1339289051.1499903224955-- .