=20 >>> void shift_right(BidirIt first, BidirIt last, unsigned int n =3D 1)=20 >>> {=20 >>> std::move_backward(first, last - n, last);=20 >>> } >>>=20 >>> This demonstrates that while std::shift is implementable with std::move= /std::move_backward, >>> 1) It isn't immediately clear from the code (at least to my eyes) that = this is a shift right, unless you are intimately familiar with std::move_ba= ckward. >>> 2) Different calls, either to std::move or to std::move_backward, are r= equired, depending on the shift direction. >>=20 >> If you're shifting the whole container's contents, you could use either = of these: >> std::move(ctr.rbegin() + n, ctr.rend(), ctr.rbegin()); >> std::move_backward(ctr.begin(), ctr.end() - n, ctr.end())? >> I don't currently see the use-case for this "shift just a piece of a con= tainer" algorithm, I mean as distinct from std::move and std::move_backward= which already exist. Do you have a use-case? >=20 > The use-case would be anytime you'd want to use the code you just wrote. = When you have a range and N, and you want to do a shift N units in that dir= ection. >=20 > The point of having it is one of clarification and user expectations. Yes= , you can use `move` and `move_backward` to accomplish a shift. But conside= r the two function calls: >=20 > //A > std::shift(rng.begin(), rng.end(), N); >=20 > //B > auto rrng =3D std::make_reverse_range(rng); > std::move(rrng.begin() + N, rrng.end(), rrng.begin()); >=20 > A and B both do the same thing. But it's a lot easier to figure out what = the code is actually accomplishing from looking at A than B. >=20 > B gets even more obtuse confusing in a range-based world: >=20 > //A > std::shift(rng, N); >=20 > //B > auto rrng =3D std::make_reverse_range(rng); > std::move(std::make_range(rrng.begin + N, rrng.end()), rrng.begin()); > --=20 > You received this message because you are subscribed to the Google Groups= "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to std-proposals+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/isoc= pp.org/d/msgid/std-proposals/c722a201-5c9c-4ac5-a1bd-e50beb6d7860%40isocpp.= org. --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+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/1E3763D6-C8A5-471A-AA44-F5CFDEDD6D9E%40gmail.com= .. --Apple-Mail-B758B76A-D759-4322-99A9-61165DC59A77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for phrasing the= motivation so well Nicol.

Arthur, regarding speci= fic use cases, any algorithm doing time series analysis (e.g. temperature t= he last 20 days) could use this.

(A cyclical buffe= r is an alternative, but one which isn't always preferrable.)

On 13 Jul 2017, at 4:43, Nicol Bolas <jmckesson@gmail.com> wrote:

On Wednesday, July 12, 2017 at 7:47:05 PM UTC-4,= Arthur O'Dwyer wrote:
On Wednesday, July 12, 2017 at 2:53:19 AM UTC-7, d...@soundradi= x.com wrote:
Hi= ,

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

It would be similar to both:=
- std::rotate, but without moving the head elements back to the = tail. This would allow a more efficient implementation and clearer semantic= s in case rotation is not needed as well as correctness in case rotation is= undesired.
- <algorithm>'s std::move/std::move_backward (d= epending on the shift direction).

std::shift shoul= d probably accommodate both left and right shifts by one of:
- gi= ving it either begin() and end(), or rbegin() and rend(), similar to how st= d::rotate works for both left and right rotations. The advantage is compact= ness 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 with rotate,= positive integers should shift to the left.
- having st= d::shift_right and std::shift_left functions. The advantage is clarity when= calling the methods, although the same argument could be made for having s= eparate std::rotate_left and std::rotate_right instead of std::rotate, whic= h we don't have.

std::rot= ate is actually just a rotation; it doesn't need "left" or "right" qualific= ation because they're 100% equivalent. Consider a classroom globe with Lond= on in front, facing you. Now "rotate" the globe until Beijing is in front. = It doesn't matter if you rotate left or rotate right; the outcome is exactl= y the same either way.

Here's a sample implementation of a shift t= o the right direction:

template<<= /span>class BidirIt&g= t; = void shift_right(BidirIt first, BidirIt last, unsigned int n =3D 1) { std::move_backward(first, last - n, last); }

This demonstrates that while std::shift is implementable wi= th std::move/std::move_backward,
1) It isn't immediately clear fr= om the code (at least to my eyes) that this is a shift right, unless you ar= e intimately familiar with std::move_backward.
2) Different calls= , either 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:

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

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

I don't currently see the use-case for this "shift = just a piece of a container" algorithm, I mean as distinct from std::move a= nd std::move_backward which already exist. Do you have a use-case?

The use-case would be anytime you'd want to use th= e code you just wrote. When you have a range and N, and you want to do a sh= ift N units in that direction.

The point of having it is one of clar= ification and user expectations. Yes, you can use `move` and `move_backward= ` to accomplish a shift. But consider the two function calls:

//A
std::shift(rng.begin(), rng.end(), N);

//B
auto rrng =3D std::make_reverse_=
range(rng);
std::move(rrng.begin() + N, rrng.end(), rrng=
..begin());

A and B both do the same thing. But it's a lot easie= r to figure out what the code is actually accomplishing from looking at= A than B.

B gets even more obtuse confusing in a range-based world:=

=
//A
std=
::<=
span style=3D"color: #000;" class=3D"styled-by-prettify">shift(rng, N);

//B
auto=
 rrng =3D std::make_reverse_range(rng);
std::move(st=
d::=
make_range=
(rrng.begin + N, rrng<=
/span>.end()), rrng.begin());

--
You received this message because you are subscribed to the Google Groups "= 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.goo= gle.com/a/isocpp.org/d/msgid/std-proposals/c722a201-5c9c-4ac5-a1bd-e50beb6d= 7860%40isocpp.org.

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/1E3763D6-C8A5-471A-AA44-F5CFDEDD6D9E%= 40gmail.com.
--Apple-Mail-B758B76A-D759-4322-99A9-61165DC59A77-- .