------=_Part_2307_1231400734.1539725012970
Content-Type: multipart/alternative;
 boundary="----=_Part_2308_1137123720.1539725012971"

------=_Part_2308_1137123720.1539725012971
Content-Type: text/plain; charset="UTF-8"

Hi,

P1223R0 proposes to add various overloads of these new functions to
<algorithm> to operate upon bidirectional iterators or ranges composed
thereof:

find_backward(), find_not_backward(), find_if_backward(),
find_if_not_backward(), find_not().

I have two suggestions:

First, there is no reason why these functions shouldn't have a
specialization that produces the obvious result when operating on a forward
iterator range (that is not bidirectional).  E.g. a possible implementation
for this specialization of find_backward() that returns an iterator
addressing the *last* element comparing equal to the search value if any
are present, otherwise the end-of-range:

template <typename ForwardIterator, typename Sentinel, typename T>
auto find_backward(ForwardIterator begin, Sentinel end, const T & val)
{
    ForwardIterator result = end;
    while (begin != end) {
        if (val == *begin)
            result = begin;
        ++begin;
    }
    return result;
}

Second: respectfully I suggest that for brevity (as well as for symmetry
with std::basic_string member functions), std::find_backward() might be
named std::rfind() instead.  This would also fix any misleading impression
that the above-suggested forward iterator specialization was somehow
traversing the range backward.

Perfect symmetry with std::basic_string is probably not desirable, since it
would imply that find_not_backward() ought to be given the terribly clunky
name find_last_not_of(), and similar.  I would suggest instead:

  find_backward --> rfind
  find_not_backward --> rfind_not
  find_if_backward --> rfind_if
  find_if_not_backward --> rfind_if_not
  [find_not remains as-is]

Thanks for considering,

--
Kevin B. McCarty
<kmccarty@gmail.com>

--
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/isocpp.org/d/msgid/std-proposals/0ea76761-bba3-4618-877a-b6d714f3a893%40isocpp.org.

------=_Part_2308_1137123720.1539725012971
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>P1223R0 proposes to add various overloads of th=
ese new functions to &lt;algorithm&gt; to operate upon bidirectional iterat=
ors or ranges composed thereof:<br><br>find_backward(), find_not_backward()=
, find_if_backward(), find_if_not_backward(), find_not().<br><br>I have two=
 suggestions:<br><br>First, there is no reason why these functions shouldn&=
#39;t have a specialization that produces the obvious result when operating=
 on a forward iterator range (that is not bidirectional).=C2=A0 E.g. a poss=
ible implementation for this specialization of find_backward() that returns=
 an iterator addressing the *last* element comparing equal to the search va=
lue if any are present, otherwise the end-of-range:<br><br>template &lt;typ=
ename ForwardIterator, typename Sentinel, typename T&gt;<br>auto find_backw=
ard(ForwardIterator begin, Sentinel end, const T &amp; val)<br>{<br>=C2=A0=
=C2=A0=C2=A0 ForwardIterator result =3D end;<br>=C2=A0=C2=A0=C2=A0 while (b=
egin !=3D end) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (val =3D=
=3D *begin)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 result =3D begin;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++be=
gin;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 return result;<br>}<br><=
br>Second: respectfully I suggest that for brevity (as well as for symmetry=
 with std::basic_string member functions), std::find_backward() might be na=
med std::rfind() instead.=C2=A0 This would also fix any misleading impressi=
on that the above-suggested forward iterator specialization was somehow tra=
versing the range backward.<br><br>Perfect symmetry with std::basic_string =
is probably not desirable, since it would imply that find_not_backward() ou=
ght to be given the terribly clunky name find_last_not_of(), and similar.=
=C2=A0 I would suggest instead:<br><br>=C2=A0 find_backward --&gt; rfind<br=
>=C2=A0 find_not_backward --&gt; rfind_not<br>=C2=A0 find_if_backward --&gt=
; rfind_if<br>=C2=A0 find_if_not_backward --&gt; rfind_if_not<br>=C2=A0 [fi=
nd_not remains as-is]<br><br>Thanks for considering,<br><br>-- <br>Kevin B.=
 McCarty<br>&lt;kmccarty@gmail.com&gt;<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0ea76761-bba3-4618-877a-b6d714f3a893%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ea76761-bba3-4618-877a-b6d714f3a893=
%40isocpp.org</a>.<br />

------=_Part_2308_1137123720.1539725012971--

------=_Part_2307_1231400734.1539725012970--

.

------=_Part_2559_880635268.1539764488785
Content-Type: multipart/alternative;
 boundary="----=_Part_2560_1880906479.1539764488786"

------=_Part_2560_1880906479.1539764488786
Content-Type: text/plain; charset="UTF-8"

I personally am against the original proposal as it does not scale - we
must add _backwards versions to all similar algorithms OR unexperienced new
user will look for them, baffled why there is no upper_bound_backwards or
something.

The user must learn about reverse iterators and the mix-and-match nature of
the STL and that he is free to create new functions by combinations of the
core algorithms and giving them names he wants.

That said I agree it is a glaring naming issue that

auto rfirst = std::make_reverse_iterator(it);
auto rlast = std::make_reverse_iterator(first);
auto it = std::find(rfirst, rlast, x);

will be the same as

auto it = std::find_backward(first, it, x);

How can one teach that?


Also, the original proposal ignores the fact make_ is no longer needed

auto it = std::find(std::reverse_iterator(it),
std::reverse_iterator(first), x);

Now, I believe this is more clear then std::find_backward(first, it, x); as
the starting iterator is it and the last iterator is first - this maps to
the mental  image, we are traversing from the back to the front

It might be subjective but I expect first to be the first in the direction
I am traversing not first in the collection/memory!



On Wednesday, October 17, 2018 at 12:23:33 AM UTC+3, kmcc...@gmail.com
wrote:
>
> Hi,
>
> P1223R0 proposes to add various overloads of these new functions to
> <algorithm> to operate upon bidirectional iterators or ranges composed
> thereof:
>
> find_backward(), find_not_backward(), find_if_backward(),
> find_if_not_backward(), find_not().
>
> I have two suggestions:
>
> First, there is no reason why these functions shouldn't have a
> specialization that produces the obvious result when operating on a forward
> iterator range (that is not bidirectional).  E.g. a possible implementation
> for this specialization of find_backward() that returns an iterator
> addressing the *last* element comparing equal to the search value if any
> are present, otherwise the end-of-range:
>
> template <typename ForwardIterator, typename Sentinel, typename T>
> auto find_backward(ForwardIterator begin, Sentinel end, const T & val)
> {
>     ForwardIterator result = end;
>     while (begin != end) {
>         if (val == *begin)
>             result = begin;
>         ++begin;
>     }
>     return result;
> }
>
> Second: respectfully I suggest that for brevity (as well as for symmetry
> with std::basic_string member functions), std::find_backward() might be
> named std::rfind() instead.  This would also fix any misleading impression
> that the above-suggested forward iterator specialization was somehow
> traversing the range backward.
>
> Perfect symmetry with std::basic_string is probably not desirable, since
> it would imply that find_not_backward() ought to be given the terribly
> clunky name find_last_not_of(), and similar.  I would suggest instead:
>
>   find_backward --> rfind
>   find_not_backward --> rfind_not
>   find_if_backward --> rfind_if
>   find_if_not_backward --> rfind_if_not
>   [find_not remains as-is]
>
> Thanks for considering,
>
> --
> Kevin B. McCarty
> <kmcc...@gmail.com <javascript:>>
>

--
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/isocpp.org/d/msgid/std-proposals/d0196072-98ab-4a53-bade-c663ed3f0b2a%40isocpp.org.

------=_Part_2560_1880906479.1539764488786
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I personally am against the original proposal as it does n=
ot scale - we must add _backwards versions to all similar algorithms OR une=
xperienced new user will look for them, baffled why there is no upper_bound=
_backwards or something.<div><br></div><div>The user must learn about rever=
se iterators and the mix-and-match nature of the STL and that he is free to=
 create new functions by combinations of the core algorithms and giving the=
m names he wants.</div><div><br></div><div>That said I agree it is a glarin=
g naming issue that</div><div><br></div><div><font face=3D"courier new, mon=
ospace">auto rfirst =3D std::make_reverse_iterator(it);=C2=A0</font></div><=
div><font face=3D"courier new, monospace">auto rlast =3D std::make_reverse_=
iterator(first);=C2=A0</font></div><div><font face=3D"courier new, monospac=
e">auto it =3D std::find(rfirst, rlast, x);</font></div><div><br></div><div=
>will be the same as</div><div><br></div><div><font face=3D"courier new, mo=
nospace">auto it =3D std::find_backward(first, it, x);</font></div><div><br=
></div><div>How can one teach that?</div><div><br></div><div><br></div><div=
>Also, the original proposal ignores the fact make_ is no longer needed</di=
v><div><br></div><div><div><font face=3D"courier new, monospace">auto it =
=3D std::find(std::reverse_iterator(it), std::reverse_iterator(first), x);<=
/font></div></div><div><br></div><div>Now, I believe this is more clear the=
n=C2=A0<span style=3D"font-family: &quot;courier new&quot;, monospace;">std=
::find_backward(first, it, x); </span><font face=3D"arial, sans-serif">as=
=C2=A0</font></div><div><font face=3D"arial, sans-serif">the starting itera=
tor is </font><font face=3D"courier new, monospace">it </font><font face=3D=
"arial, sans-serif">and the last iterator is </font><font face=3D"courier n=
ew, monospace">first </font><font face=3D"arial, sans-serif">- this maps to=
 the mental=C2=A0 image, we are traversing from the back to the front</font=
></div><div><br></div><div>It might be subjective but I expect first to be =
the first in the direction I am traversing not first in the collection/memo=
ry!</div><div><br></div><div><br></div><div><br>On Wednesday, October 17, 2=
018 at 12:23:33 AM UTC+3, kmcc...@gmail.com wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">Hi,<br><br>P1223R0 proposes to add var=
ious overloads of these new functions to &lt;algorithm&gt; to operate upon =
bidirectional iterators or ranges composed thereof:<br><br>find_backward(),=
 find_not_backward(), find_if_backward(), find_if_not_backward(), find_not(=
).<br><br>I have two suggestions:<br><br>First, there is no reason why thes=
e functions shouldn&#39;t have a specialization that produces the obvious r=
esult when operating on a forward iterator range (that is not bidirectional=
).=C2=A0 E.g. a possible implementation for this specialization of find_bac=
kward() that returns an iterator addressing the *last* element comparing eq=
ual to the search value if any are present, otherwise the end-of-range:<br>=
<br>template &lt;typename ForwardIterator, typename Sentinel, typename T&gt=
;<br>auto find_backward(ForwardIterator begin, Sentinel end, const T &amp; =
val)<br>{<br>=C2=A0=C2=A0=C2=A0 ForwardIterator result =3D end;<br>=C2=A0=
=C2=A0=C2=A0 while (begin !=3D end) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 if (val =3D=3D *begin)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 result =3D begin;<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 ++begin;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 r=
eturn result;<br>}<br><br>Second: respectfully I suggest that for brevity (=
as well as for symmetry with std::basic_string member functions), std::find=
_backward() might be named std::rfind() instead.=C2=A0 This would also fix =
any misleading impression that the above-suggested forward iterator special=
ization was somehow traversing the range backward.<br><br>Perfect symmetry =
with std::basic_string is probably not desirable, since it would imply that=
 find_not_backward() ought to be given the terribly clunky name find_last_n=
ot_of(), and similar.=C2=A0 I would suggest instead:<br><br>=C2=A0 find_bac=
kward --&gt; rfind<br>=C2=A0 find_not_backward --&gt; rfind_not<br>=C2=A0 f=
ind_if_backward --&gt; rfind_if<br>=C2=A0 find_if_not_backward --&gt; rfind=
_if_not<br>=C2=A0 [find_not remains as-is]<br><br>Thanks for considering,<b=
r><br>-- <br>Kevin B. McCarty<br>&lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"hUYddHv_BQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">kmcc...@gmail.com</a>&gt;<br></div></blockq=
uote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d0196072-98ab-4a53-bade-c663ed3f0b2a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0196072-98ab-4a53-bade-c663ed3f0b2a=
%40isocpp.org</a>.<br />

------=_Part_2560_1880906479.1539764488786--

------=_Part_2559_880635268.1539764488785--

.