------=_Part_1170_367923296.1419489640214
Content-Type: multipart/alternative;
 boundary="----=_Part_1171_1081416159.1419489640214"

------=_Part_1171_1081416159.1419489640214
Content-Type: text/plain; charset=UTF-8

Hi guys,

Range-for and auto greatly simplify code dealing with iterators - thanks to
all who contributed to that - but don't you think it's an omission we still
don't have the very simple *bool* *contains(const T&)* family in STL
containers?

There's hardly a single production codebase in the world that doesn't have
the contains() boilerplate (I mean, of course, comparing the result of
find() to an end() to see if the value is there), often in multiple places.
And I guess range-for and auto were also at least partly born out of
realization that our code often deserves a higher abstraction level than
iterators.

Correct me if I'm wrong, but I see contains() as a not-so-big of an
addition to the standard library that would be of quite significant value.

Regards,
Leo

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1171_1081416159.1419489640214
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi guys,<div><br><div><span style=3D"font-size: 13.3333330=
154419px;">Range-</span><font color=3D"#0000ff" style=3D"font-size: 13.3333=
330154419px;">for</font><span style=3D"font-size: 13.3333330154419px;"> and=
 </span><font color=3D"#0000ff" style=3D"font-size: 13.3333330154419px;">au=
to</font><span style=3D"font-size: 13.3333330154419px;"> greatly simplify c=
ode dealing with iterators - thanks to all who contributed to that - but do=
n't you think it's an&nbsp;</span>omission<span style=3D"font-size: 13.3333=
330154419px;">&nbsp;we still don't have the very simple&nbsp;<font color=3D=
"#0000ff"><b>bool</b></font>&nbsp;</span><b style=3D"font-size: 13.33333301=
54419px;">contains(const T&amp;)</b><span style=3D"font-size: 13.3333330154=
419px;">&nbsp;family in STL containers?</span><br></div><div><br></div><div=
>There's hardly a single production codebase in the world that doesn't have=
 the contains() boilerplate (I mean, of course, comparing the result of fin=
d() to an end() to see if the value is there), often in multiple places. An=
d I guess r<span style=3D"font-size: 13.3333330154419px;">ange-</span><font=
 color=3D"#0000ff" style=3D"font-size: 13.3333330154419px;">for</font><span=
 style=3D"font-size: 13.3333330154419px;">&nbsp;and&nbsp;</span><font color=
=3D"#0000ff" style=3D"font-size: 13.3333330154419px;">auto</font><span styl=
e=3D"font-size: 13px;">&nbsp;were also at least partly born out of realizat=
ion that our code often deserves a higher abstraction level than iterators.=
</span></div><div><span style=3D"font-size: 13px;"><br></span></div><div><s=
pan style=3D"font-size: 13px;">Correct me if I'm wrong, but I see contains(=
) as a not-so-big of an addition to the standard library that would be of q=
uite significant value.</span></div><div><br></div><div>Regards,</div><div>=
Leo</div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1171_1081416159.1419489640214--
------=_Part_1170_367923296.1419489640214--

.

------=_Part_727_2021846481.1419513756483
Content-Type: multipart/alternative;
 boundary="----=_Part_728_1540059686.1419513756483"

------=_Part_728_1540059686.1419513756483
Content-Type: text/plain; charset=UTF-8

I agree that such an algorithm would be beneficial, but I would rather have
it implemented as a global function. This way we would not pollute the
interface of standard containers with functions that can be implemented
without accessing their private data. Also, a global std::contains() could
be overloaded for array types.

If the concern is with the inconsistent syntax between, say, "contains(c,
elem)" and "c.size()", then this may be addressed by the recent proposals
(e.g. this one
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf>) about
introducing uniform function call syntax.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_728_1540059686.1419513756483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree that such an algorithm would be beneficial, but I =
would rather have it implemented as a global function. This way we would no=
t pollute the interface of standard containers with functions that can be i=
mplemented without accessing their private data. Also, a global std::contai=
ns() could be overloaded for array types.<br><br>If the concern is with the=
 inconsistent syntax between, say, "contains(c, elem)" and "c.size()", then=
 this may be addressed by the recent proposals (e.g. <a href=3D"http://www.=
open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf">this one</a>) about=
 introducing uniform function call syntax.<br><br>Kind regards,<br><br>Andy=
</div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_728_1540059686.1419513756483--
------=_Part_727_2021846481.1419513756483--

.

------=_Part_115_609933341.1419513855345
Content-Type: multipart/alternative;
 boundary="----=_Part_116_1210215056.1419513855345"

------=_Part_116_1210215056.1419513855345
Content-Type: text/plain; charset=UTF-8

(actually, overloading for array types would be unnecessary, because the
implementation would use global std::begin() and std::end(), which are in
turn overloaded for array types).

On Thursday, December 25, 2014 2:22:36 PM UTC+1, Andy Prowl wrote:
>
> I agree that such an algorithm would be beneficial, but I would rather
> have it implemented as a global function. This way we would not pollute the
> interface of standard containers with functions that can be implemented
> without accessing their private data. Also, a global std::contains() could
> be overloaded for array types.
>
> If the concern is with the inconsistent syntax between, say, "contains(c,
> elem)" and "c.size()", then this may be addressed by the recent proposals
> (e.g. this one
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf>)
> about introducing uniform function call syntax.
>
> Kind regards,
>
> Andy
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_116_1210215056.1419513855345
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">(actually, overloading for array types would be unnecessar=
y, because the implementation would use global std::begin() and std::end(),=
 which are in turn overloaded for array types).<br><br>On Thursday, Decembe=
r 25, 2014 2:22:36 PM UTC+1, Andy Prowl wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">I agree that such an algorithm would be be=
neficial, but I would rather have it implemented as a global function. This=
 way we would not pollute the interface of standard containers with functio=
ns that can be implemented without accessing their private data. Also, a gl=
obal std::contains() could be overloaded for array types.<br><br>If the con=
cern is with the inconsistent syntax between, say, "contains(c, elem)" and =
"c.size()", then this may be addressed by the recent proposals (e.g. <a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf" tar=
get=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn=
4174.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHkJMV_PrQigQyYiudR49Ler99jVw';r=
eturn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4174.p=
df\46sa\75D\46sntz\0751\46usg\75AFQjCNHkJMV_PrQigQyYiudR49Ler99jVw';return =
true;">this one</a>) about introducing uniform function call syntax.<br><br=
>Kind regards,<br><br>Andy</div></blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_116_1210215056.1419513855345--
------=_Part_115_609933341.1419513855345--

.

------=_Part_201_778139214.1419525852682
Content-Type: multipart/alternative;
 boundary="----=_Part_202_10359468.1419525852682"

------=_Part_202_10359468.1419525852682
Content-Type: text/plain; charset=UTF-8

On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
>
> Hi guys,
>
> Range-for and auto greatly simplify code dealing with iterators - thanks
> to all who contributed to that - but don't you think it's an omission we
> still don't have the very simple *bool* *contains(const T&)* family in
> STL containers?
>
> There's hardly a single production codebase in the world that doesn't have
> the contains() boilerplate (I mean, of course, comparing the result of
> find() to an end() to see if the value is there), often in multiple places.
> And I guess range-for and auto were also at least partly born out of
> realization that our code often deserves a higher abstraction level than
> iterators.
>
> Correct me if I'm wrong, but I see contains() as a not-so-big of an
> addition to the standard library that would be of quite significant value.
>

Hi Leo,

If it's about maps etc you could use count() or a find wrapper that returns
a pointer (to second) for simpler syntax.
contains() might still be useful.

Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_202_10359468.1419525852682
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heins=
aar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi =
guys,<div><br><div><span style=3D"font-size:13.3333330154419px">Range-</spa=
n><font color=3D"#0000ff" style=3D"font-size:13.3333330154419px">for</font>=
<span style=3D"font-size:13.3333330154419px"> and </span><font color=3D"#00=
00ff" style=3D"font-size:13.3333330154419px">auto</font><span style=3D"font=
-size:13.3333330154419px"> greatly simplify code dealing with iterators - t=
hanks to all who contributed to that - but don't you think it's an&nbsp;</s=
pan>omission<span style=3D"font-size:13.3333330154419px">&nbsp;we still don=
't have the very simple&nbsp;<font color=3D"#0000ff"><b>bool</b></font>&nbs=
p;</span><b style=3D"font-size:13.3333330154419px">contains(const T&amp;)</=
b><span style=3D"font-size:13.3333330154419px">&nbsp;family in STL containe=
rs?</span><br></div><div><br></div><div>There's hardly a single production =
codebase in the world that doesn't have the contains() boilerplate (I mean,=
 of course, comparing the result of find() to an end() to see if the value =
is there), often in multiple places. And I guess r<span style=3D"font-size:=
13.3333330154419px">ange-</span><font color=3D"#0000ff" style=3D"font-size:=
13.3333330154419px">for</font><span style=3D"font-size:13.3333330154419px">=
&nbsp;and&nbsp;</span><font color=3D"#0000ff" style=3D"font-size:13.3333330=
154419px">auto</font><span style=3D"font-size:13px">&nbsp;were also at leas=
t partly born out of realization that our code often deserves a higher abst=
raction level than iterators.</span></div><div><span style=3D"font-size:13p=
x"><br></span></div><div><span style=3D"font-size:13px">Correct me if I'm w=
rong, but I see contains() as a not-so-big of an addition to the standard l=
ibrary that would be of quite significant value.</span></div></div></div></=
blockquote><div><br></div><div>Hi Leo,</div><div><br></div><div>If it's abo=
ut maps etc you could use count() or a find wrapper that returns a pointer =
(to second) for simpler syntax.</div><div>contains() might still be useful.=
</div><div><br></div><div>Olaf&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_202_10359468.1419525852682--
------=_Part_201_778139214.1419525852682--

.

------=_Part_3389_1721590067.1419534078883
Content-Type: multipart/alternative;
 boundary="----=_Part_3390_1717080038.1419534078883"

------=_Part_3390_1717080038.1419534078883
Content-Type: text/plain; charset=UTF-8

Andy, I really don't think it's even worth going into the trouble to
standardize the *contains(c, elem)* syntax. We might as well continue to
write those functions ourselves - which is exactly my point: unlike with
the *contains(c, elem)* syntax, we *can't* write *c.contains(elem)*
ourselves unless we first define c's type deriving from a standard
container, or including the standard container as a member and providing a
*contains()* method.

I really disagree that a method so natural for containers as *contains()* will
be a pollution to their interfaces.

Leo

On Thursday, December 25, 2014 5:22:36 PM UTC+4, Andy Prowl wrote:
>
> I agree that such an algorithm would be beneficial, but I would rather
> have it implemented as a global function. This way we would not pollute the
> interface of standard containers with functions that can be implemented
> without accessing their private data. Also, a global std::contains() could
> be overloaded for array types.
>
> If the concern is with the inconsistent syntax between, say, "contains(c,
> elem)" and "c.size()", then this may be addressed by the recent proposals
> (e.g. this one
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf>)
> about introducing uniform function call syntax.
>
> Kind regards,
>
> Andy
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_3390_1717080038.1419534078883
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Andy, I really don't think it's even worth going into the =
trouble to standardize the <b>contains(c, elem)</b> syntax. We might as wel=
l continue to write those functions ourselves - which is exactly my point: =
unlike with the&nbsp;<b>contains(c, elem)</b>&nbsp;syntax,&nbsp;we <i>can't=
</i> write <b>c.contains(elem)</b> ourselves unless we first define c's typ=
e deriving from a standard container, or including the standard container a=
s a member and providing a <b>contains()</b> method.<div><br></div><div>I r=
eally disagree that a method so natural for containers as&nbsp;<b>contains(=
)</b>&nbsp;will be a pollution to their interfaces.<br><div><br></div><div>=
Leo</div><div><br>On Thursday, December 25, 2014 5:22:36 PM UTC+4, Andy Pro=
wl wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I ag=
ree that such an algorithm would be beneficial, but I would rather have it =
implemented as a global function. This way we would not pollute the interfa=
ce of standard containers with functions that can be implemented without ac=
cessing their private data. Also, a global std::contains() could be overloa=
ded for array types.<br><br>If the concern is with the inconsistent syntax =
between, say, "contains(c, elem)" and "c.size()", then this may be addresse=
d by the recent proposals (e.g. <a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2014/n4174.pdf" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2F=
sc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4174.pdf\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHkJMV_PrQigQyYiudR49Ler99jVw';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4174.pdf\46sa\75D\46sntz\0751\46usg\75AFQjC=
NHkJMV_PrQigQyYiudR49Ler99jVw';return true;">this one</a>) about introducin=
g uniform function call syntax.<br><br>Kind regards,<br><br>Andy</div></blo=
ckquote></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3390_1717080038.1419534078883--
------=_Part_3389_1721590067.1419534078883--

.

------=_Part_664_355698296.1419534179827
Content-Type: multipart/alternative;
 boundary="----=_Part_665_1774271271.1419534179828"

------=_Part_665_1774271271.1419534179828
Content-Type: text/plain; charset=UTF-8

Hi Olaf - same argument from me as just wrote to Andy.

Thanks,
Leo

On Thursday, December 25, 2014 8:44:12 PM UTC+4, Olaf van der Spek wrote:
>
> On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
>>
>> Hi guys,
>>
>> Range-for and auto greatly simplify code dealing with iterators - thanks
>> to all who contributed to that - but don't you think it's an omission we
>> still don't have the very simple *bool* *contains(const T&)* family in
>> STL containers?
>>
>> There's hardly a single production codebase in the world that doesn't
>> have the contains() boilerplate (I mean, of course, comparing the result of
>> find() to an end() to see if the value is there), often in multiple places.
>> And I guess range-for and auto were also at least partly born out of
>> realization that our code often deserves a higher abstraction level than
>> iterators.
>>
>> Correct me if I'm wrong, but I see contains() as a not-so-big of an
>> addition to the standard library that would be of quite significant value.
>>
>
> Hi Leo,
>
> If it's about maps etc you could use count() or a find wrapper that
> returns a pointer (to second) for simpler syntax.
> contains() might still be useful.
>
> Olaf
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_665_1774271271.1419534179828
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Olaf - same argument from me as just wrote to Andy.<div=
><br></div><div>Thanks,</div><div>Leo<br><br>On Thursday, December 25, 2014=
 8:44:12 PM UTC+4, Olaf van der Spek wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr">On Thursday, December 25, 2014 7:40:40 AM UTC=
+1, Leo Heinsaar wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">Hi guys,<div><br><div><span style=3D"font-size:13.3333330154419px">Ran=
ge-</span><font color=3D"#0000ff" style=3D"font-size:13.3333330154419px">fo=
r</font><span style=3D"font-size:13.3333330154419px"> and </span><font colo=
r=3D"#0000ff" style=3D"font-size:13.3333330154419px">auto</font><span style=
=3D"font-size:13.3333330154419px"> greatly simplify code dealing with itera=
tors - thanks to all who contributed to that - but don't you think it's an&=
nbsp;</span>omission<span style=3D"font-size:13.3333330154419px">&nbsp;we s=
till don't have the very simple&nbsp;<font color=3D"#0000ff"><b>bool</b></f=
ont>&nbsp;</span><b style=3D"font-size:13.3333330154419px">contains(const T=
&amp;)</b><span style=3D"font-size:13.3333330154419px">&nbsp;family in STL =
containers?</span><br></div><div><br></div><div>There's hardly a single pro=
duction codebase in the world that doesn't have the contains() boilerplate =
(I mean, of course, comparing the result of find() to an end() to see if th=
e value is there), often in multiple places. And I guess r<span style=3D"fo=
nt-size:13.3333330154419px">ange-</span><font color=3D"#0000ff" style=3D"fo=
nt-size:13.3333330154419px">for</font><span style=3D"font-size:13.333333015=
4419px">&nbsp;and&nbsp;</span><font color=3D"#0000ff" style=3D"font-size:13=
..3333330154419px">auto</font><span style=3D"font-size:13px">&nbsp;were also=
 at least partly born out of realization that our code often deserves a hig=
her abstraction level than iterators.</span></div><div><span style=3D"font-=
size:13px"><br></span></div><div><span style=3D"font-size:13px">Correct me =
if I'm wrong, but I see contains() as a not-so-big of an addition to the st=
andard library that would be of quite significant value.</span></div></div>=
</div></blockquote><div><br></div><div>Hi Leo,</div><div><br></div><div>If =
it's about maps etc you could use count() or a find wrapper that returns a =
pointer (to second) for simpler syntax.</div><div>contains() might still be=
 useful.</div><div><br></div><div>Olaf&nbsp;</div></div></blockquote></div>=
</div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_665_1774271271.1419534179828--
------=_Part_664_355698296.1419534179827--

.

------=_Part_5996_985172596.1419536795199
Content-Type: multipart/alternative;
 boundary="----=_Part_5997_696902602.1419536795199"

------=_Part_5997_696902602.1419536795199
Content-Type: text/plain; charset=UTF-8

On Thursday, December 25, 2014 8:01:18 PM UTC+1, Leo Heinsaar wrote:
>
> Andy, I really don't think it's even worth going into the trouble to
> standardize the *contains(c, elem)* syntax. We might as well continue to
> write those functions ourselves - which is exactly my point: unlike with
> the *contains(c, elem)* syntax, we *can't* write *c.contains(elem)*
> ourselves unless we first define c's type deriving from a standard
> container, or including the standard container as a member and providing a
> *contains()* method.
>

As I wrote, if the problem is *syntactical*, then it might be solved by the
above-mentioned proposals. While I do understand that
"subject.verb(object)" reads somewhat more familiar than "verb(subject,
object)", I would not forget about the engineering consequences of making
contains() a member function, i.e. non-minimal interfaces that include more
functions than they need to. Scott Meyers and Alex Stepanov have written
extensively about this.

This is a general problem, not specific to contains() and containers:
hence, it should be addressed generally. Many function calls are easier to
write (thanks to IDE support) using the dot notation, but that doesn't mean
we should make all those functions members. IMO the right way of addressing
the problem of syntactic consistency for member and non-member function
calls (if we want to address it) is to support some sort of UFCS as
proposed (independently) by Herb and Bjarne. Just my two cents.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5997_696902602.1419536795199
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, December 25, 2014 8:01:18 PM UTC+1, Leo Heins=
aar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">And=
y, I really don't think it's even worth going into the trouble to standardi=
ze the <b>contains(c, elem)</b> syntax. We might as well continue to write =
those functions ourselves - which is exactly my point: unlike with the&nbsp=
;<b>contains(c, elem)</b>&nbsp;syntax,&nbsp;we <i>can't</i> write <b>c.cont=
ains(elem)</b> ourselves unless we first define c's type deriving from a st=
andard container, or including the standard container as a member and provi=
ding a <b>contains()</b> method.</div></blockquote><div><br></div><div>As I=
 wrote, if the problem is&nbsp;<i>syntactical</i>, then it might be solved =
by the above-mentioned proposals. While I do understand that "subject.verb(=
object)" reads somewhat more familiar than "verb(subject, object)", I would=
 not forget about the engineering consequences of making contains() a membe=
r function, i.e. non-minimal interfaces that include more functions than th=
ey need to. Scott Meyers and Alex Stepanov have written extensively about t=
his.&nbsp;<br><br>This is a general problem, not specific to contains() and=
 containers: hence, it should be addressed generally. Many function calls a=
re easier to write (thanks to IDE support) using the dot notation, but that=
 doesn't mean we should make all those functions members. IMO the right way=
 of addressing the problem of syntactic consistency for member and non-memb=
er function calls (if we want to address it) is to support some sort of UFC=
S as proposed&nbsp;<span style=3D"font-size: 13.3333330154419px;">(independ=
ently)</span><span style=3D"font-size: 13.3333330154419px;">&nbsp;</span><s=
pan style=3D"font-size: 13px;">by Herb and Bjarne. Just my two cents.</span=
></div><div><br>Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5997_696902602.1419536795199--
------=_Part_5996_985172596.1419536795199--

.

------=_Part_32_963474969.1419586253765
Content-Type: multipart/alternative;
 boundary="----=_Part_33_1097105603.1419586253765"

------=_Part_33_1097105603.1419586253765
Content-Type: text/plain; charset=UTF-8


>
> As I wrote, if the problem is *syntactical*, then it might be solved by
> the above-mentioned proposals. While I do understand that
> "subject.verb(object)" reads somewhat more familiar than "verb(subject,
> object)", I would not forget about the engineering consequences of making
> contains() a member function, i.e. non-minimal interfaces that include more
> functions than they need to. Scott Meyers and Alex Stepanov have written
> extensively about this.


Sorry Andy - I took a closer look at Bjarne's proposal; it seems like if it
goes through, we'll indeed be able to have a global *contains()* with all
the benefits with respect to having it for arrays and such, invokable via
*vec.contains(x)* syntax. (It really is about nicer syntax as well as less
- a lot less - typing.)

If that's the case, then the problem is simply one step further: we simply
need a global *contains()*. By the way, I guess that opens doors for other
improvements as well.

Thanks for pointing out.

Kind regards,
Leo

On Thursday, December 25, 2014 11:46:35 PM UTC+4, Andy Prowl wrote:
>
> On Thursday, December 25, 2014 8:01:18 PM UTC+1, Leo Heinsaar wrote:
>>
>> Andy, I really don't think it's even worth going into the trouble to
>> standardize the *contains(c, elem)* syntax. We might as well continue to
>> write those functions ourselves - which is exactly my point: unlike with
>> the *contains(c, elem)* syntax, we *can't* write *c.contains(elem)*
>> ourselves unless we first define c's type deriving from a standard
>> container, or including the standard container as a member and providing a
>> *contains()* method.
>>
>
> As I wrote, if the problem is *syntactical*, then it might be solved by
> the above-mentioned proposals. While I do understand that
> "subject.verb(object)" reads somewhat more familiar than "verb(subject,
> object)", I would not forget about the engineering consequences of making
> contains() a member function, i.e. non-minimal interfaces that include more
> functions than they need to. Scott Meyers and Alex Stepanov have written
> extensively about this.
>
> This is a general problem, not specific to contains() and containers:
> hence, it should be addressed generally. Many function calls are easier to
> write (thanks to IDE support) using the dot notation, but that doesn't mean
> we should make all those functions members. IMO the right way of addressing
> the problem of syntactic consistency for member and non-member function
> calls (if we want to address it) is to support some sort of UFCS as
> proposed (independently) by Herb and Bjarne. Just my two cents.
>
> Kind regards,
>
> Andy
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_33_1097105603.1419586253765
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;"><span style=3D"font-size: 13.=
3333330154419px;">As I wrote, if the problem is&nbsp;</span><i style=3D"fon=
t-size: 13.3333330154419px;">syntactical</i><span style=3D"font-size: 13.33=
33330154419px;">, then it might be solved by the above-mentioned proposals.=
 While I do understand that "subject.verb(object)" reads somewhat more fami=
liar than "verb(subject, object)", I would not forget about the engineering=
 consequences of making contains() a member function, i.e. non-minimal inte=
rfaces that include more functions than they need to. Scott Meyers and Alex=
 Stepanov have written extensively about this.&nbsp;</span></blockquote><di=
v><br></div><div>Sorry Andy - I took a closer look at Bjarne's proposal; it=
 seems like if it goes through, we'll indeed be able to have a global <b>co=
ntains()</b>&nbsp;with all the benefits with respect to having it for array=
s and such, invokable via&nbsp;<b>vec.contains(x)</b> syntax. (It really is=
&nbsp;about nicer syntax as well as less - a lot less - typing.)</div><div>=
<br></div><div>If that's the case, then the problem is simply one step furt=
her: we simply need a global <b>contains()</b>. By the way, I guess that op=
ens doors for other improvements as well.</div><div><br></div><div>Thanks f=
or pointing out.</div><div><br></div><div>Kind regards,</div><div>Leo</div>=
<div><br>On Thursday, December 25, 2014 11:46:35 PM UTC+4, Andy Prowl wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Thursday,=
 December 25, 2014 8:01:18 PM UTC+1, Leo Heinsaar wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Andy, I really don't think it's eve=
n worth going into the trouble to standardize the <b>contains(c, elem)</b> =
syntax. We might as well continue to write those functions ourselves - whic=
h is exactly my point: unlike with the&nbsp;<b>contains(c, elem)</b>&nbsp;s=
yntax,&nbsp;we <i>can't</i> write <b>c.contains(elem)</b> ourselves unless =
we first define c's type deriving from a standard container, or including t=
he standard container as a member and providing a <b>contains()</b> method.=
</div></blockquote><div><br></div><div>As I wrote, if the problem is&nbsp;<=
i>syntactical</i>, then it might be solved by the above-mentioned proposals=
.. While I do understand that "subject.verb(object)" reads somewhat more fam=
iliar than "verb(subject, object)", I would not forget about the engineerin=
g consequences of making contains() a member function, i.e. non-minimal int=
erfaces that include more functions than they need to. Scott Meyers and Ale=
x Stepanov have written extensively about this.&nbsp;<br><br>This is a gene=
ral problem, not specific to contains() and containers: hence, it should be=
 addressed generally. Many function calls are easier to write (thanks to ID=
E support) using the dot notation, but that doesn't mean we should make all=
 those functions members. IMO the right way of addressing the problem of sy=
ntactic consistency for member and non-member function calls (if we want to=
 address it) is to support some sort of UFCS as proposed&nbsp;<span style=
=3D"font-size:13.3333330154419px">(independently)</span><span style=3D"font=
-size:13.3333330154419px">&nbsp;</span><span style=3D"font-size:13px">by He=
rb and Bjarne. Just my two cents.</span></div><div><br>Kind regards,<br><br=
>Andy</div></div></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_33_1097105603.1419586253765--
------=_Part_32_963474969.1419586253765--

.

------=_Part_97_1971129801.1419606248216
Content-Type: multipart/alternative;
 boundary="----=_Part_98_1695826785.1419606248217"

------=_Part_98_1695826785.1419606248217
Content-Type: text/plain; charset=UTF-8

On Friday, December 26, 2014 10:30:53 AM UTC+1, Leo Heinsaar wrote:

Sorry Andy - I took a closer look at Bjarne's proposal; it seems like if it
> goes through, we'll indeed be able to have a global *contains()* with all
> the benefits with respect to having it for arrays and such, invokable via
> *vec.contains(x)* syntax. (It really is about nicer syntax as well as
> less - a lot less - typing.)
>
> If that's the case, then the problem is simply one step further: we simply
> need a global *contains()*. By the way, I guess that opens doors for
> other improvements as well.
>

Indeed, that was my point. For now we could standardize std::contains() as
a non-member function. This would at least make the functionality available
as a standard algorithm, which is shamefully missing. This way people would
not have to write their own version every time.

Then, we could address the syntactic convenience of v.contains(x) over
contains(x, v) in a more general way, rather than specifically for one
single function.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_98_1695826785.1419606248217
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 26, 2014 10:30:53 AM UTC+1, Leo Heinsa=
ar wrote:<div><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>Sorry Andy - I took a closer look at Bjarne's proposal; it seems =
like if it goes through, we'll indeed be able to have a global <b>contains(=
)</b>&nbsp;with all the benefits with respect to having it for arrays and s=
uch, invokable via&nbsp;<b>vec.contains(x)</b> syntax. (It really is&nbsp;a=
bout nicer syntax as well as less - a lot less - typing.)</div><div><br></d=
iv><div>If that's the case, then the problem is simply one step further: we=
 simply need a global <b>contains()</b>. By the way, I guess that opens doo=
rs for other improvements as well.</div></div></blockquote><div><br></div><=
/div><div>Indeed, that was my point. For now we could standardize std::cont=
ains() as a non-member function. This would at least make the functionality=
 available as a standard algorithm, which is shamefully missing. This way p=
eople would not have to write their own version every time.<br><br>Then, we=
 could address the syntactic convenience of v.contains(x) over contains(x, =
v) in a more general way, rather than specifically for one single function.=
<br><br>Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_98_1695826785.1419606248217--
------=_Part_97_1971129801.1419606248216--

.

On 2014-12-26 12:07, Leo Heinsaar wrote:
>
> On Friday, December 26, 2014 8:29:19 PM UTC+4, Olaf van der Spek wrote:
>>
>> On Fri, Dec 26, 2014 at 2:31 PM, Leo Heinsaar <leohe...@gmail.com
>> <javascript:>> wrote:
>>> On Friday, December 26, 2014 4:50:15 PM UTC+4, Olaf van der Spek wrote:
>>>>
>>>> On Fri, Dec 26, 2014 at 10:30 AM, Leo Heinsaar <leohe...@gmail.com>
>> wrote:
>>>>> Sorry Andy - I took a closer look at Bjarne's proposal; it seems like
>> if
>>>>> it
>>>>> goes through, we'll indeed be able to have a global contains() with
>> all
>>>>> the
>>>>> benefits with respect to having it for arrays and such, invokable via
>>>>> vec.contains(x) syntax. (It really is about nicer syntax as well as
>> less
>>>>> - a
>>>>> lot less - typing.)
>>>>
>>>> How is it less typing? Auto-complete?
>>>
>>>
>>> Since we'll be able to simply write
>>>
>>> phone_book.contains(number)
>>>
>>> instead of:
>>>
>>> phone_book.find(number) != phone_book.end()
>>>
>>> Not to mention how much more clearly the simplified version, as they
>> like to
>>> call it, expresses intent.
>>
>> I thought that was an argument against a free function.
>> Today one can already write phone_book.count(number);
>>
>
> Oh sorry Olaf, I misunderstood; when I responded to Andy by saying, "It
> really is about nicer syntax as well as less - a lot less - typing.", I
> meant the convenience of having *contains()* versus not having it at all.
>
> I guess *phone_book.count(number)* does more work than is necessary for
> *contains()*; may not be suitable for every situation.

I would *hope* that non-multi-key containers optimize ::count() to be as
efficient as ::contains() would be (and indeed, I've been known to use
this trick before).

Actually, what would probably be better is if I could write:

    if (auto&& iter = container.find(key))

....since in most cases I then want to do something with the element, so
already having the iterator is convenient. What's really inconvenient is
having to write 'container.end()' and a separate line (one level higher
in scope) to store the iterator because I can't both declare and assign
the iterator, and compare it to end, in the same line.

Maybe we could instead create a form of ::find() that returns an
optional<iterator> or checked_iterator or similar, that can be
implicitly cast to bool to test for validity.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-12-26 12:33, Olaf van der Spek wrote:
> On Fri, Dec 26, 2014 at 6:29 PM, Matthew Woehlke wrote:
>> Maybe we could instead create a form of ::find() that returns an
>> optional<iterator> or checked_iterator or similar, that can be
>> implicitly cast to bool to test for validity.
>
> if (auto p = find_ptr(key))
>
> https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/find_ptr.h

It would be better if I can recover the iterator. Maybe I want to do
something with the item and then remove it...

(Still... something like that, *standardized*, would be an improvement.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-12-26 13:02, Andy Prowl wrote:
> While I agree with most of what has been written in the last few messages,
> I feel we are slowly diverging from the purpose of the original post,
> perhaps unnecessarily enlarging its scope.

I'm not sure I agree. If we could write:

  if (auto&& iter = container.find(key))

....do we really still need a 'contains' function? We've still solved the
problem of having to write '!= container.end()', but with the advantage
that if we also want to actually do something with the item, we already
have it and don't need to look it up again. (And this shouldn't add
significant overhead vs. returning a bool directly.)

Note that you could just as easily write:

  if (container.find(key))

....which has the exact same semantics as the proposed 'contains'.

(Be aware that, while I've been using "find", probably this API would
have some other, new name, unless we can somehow add implicit validity
checking to iterator, which seems unlikely.)

On 2014-12-26 13:18, Leo Heinsaar wrote:
> If we want to recover an iterator, we just use find(), don't we?
> (And in cases like that the code usually isn't concerned about the
> existence of an element in a container, but wants to do something.)

....but we still have to write out the '!= end' check to test if the
iterator is valid, which is what this thread is about avoiding. As I see
it, a checked-iterator form of 'find' would supersede the use of a
'contains' function and would be useful in more cases.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_6352_1163391689.1419626402474
Content-Type: multipart/alternative;
 boundary="----=_Part_6353_285511088.1419626402475"

------=_Part_6353_285511088.1419626402475
Content-Type: text/plain; charset=UTF-8

On Friday, December 26, 2014 7:56:48 PM UTC+1, Matthew Woehlke wrote:
>
>
> I'm not sure I agree. If we could write:
>
>   if (auto&& iter = container.find(key))
>
> ...do we really still need a 'contains' function?


I think we do. We're talking about containers. Their main function is to
contain stuff. It sounds just natural to have an algorithm called
"contains". People would find it easier to understand than "looking for an
element, binding a forwarding reference to a temporary iterator, and
exploiting the explicit conversion to bool".

We *could* call the function above "contains()", as long as it can be used
as if it returned a bool. That would make the "check-only" use case
intuitive, but the "element-retrieving" use case would look weird.

To conclude, IMO what is essential to have is a standard "contains()";
other algorithms *may* be added, but I don't find it compelling.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6353_285511088.1419626402475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 26, 2014 7:56:48 PM UTC+1, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>I'm not sure I =
agree. If we could write:
<br>
<br>&nbsp; if (auto&amp;&amp; iter =3D container.find(key))
<br>
<br>...do we really still need a 'contains' function? </blockquote><div><br=
></div><div>I think we do. We're talking about containers. Their main funct=
ion is to contain stuff. It sounds just natural to have an algorithm called=
 "contains". People would find it easier to understand than "looking for an=
 element, binding a forwarding reference to a temporary iterator, and explo=
iting the explicit conversion to bool".<br><br>We <i>could</i> call the fun=
ction above "contains()", as long as it can be used as if it returned a boo=
l. That would make the "check-only" use case intuitive, but the "element-re=
trieving" use case would look weird.<br><br>To conclude, IMO what is essent=
ial to have is a standard "contains()"; other algorithms <i>may</i> be adde=
d, but I don't find it compelling.<br><br>Kind regards,<br><br>Andy</div></=
div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6353_285511088.1419626402475--
------=_Part_6352_1163391689.1419626402474--

.

------=_Part_6621_1473751347.1419641396817
Content-Type: multipart/alternative;
 boundary="----=_Part_6622_262504531.1419641396817"

------=_Part_6622_262504531.1419641396817
Content-Type: text/plain; charset=UTF-8

Doesn't the "any_of" algorithm serve this purpose?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6622_262504531.1419641396817
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Doesn't the "any_of" algorithm serve this purpose?</div>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_6622_262504531.1419641396817--
------=_Part_6621_1473751347.1419641396817--

.

On 2014-12-26 22:10, Thiago Macieira wrote:
> On Saturday 27 December 2014 01:52:21 Olaf van der Spek wrote:
>> On Fri, Dec 26, 2014 at 9:40 PM, Andy Prowl <andy.prowl@gmail.com> wrote:
>>> To conclude, IMO what is essential to have is a standard "contains()";
>>> other algorithms may be added, but I don't find it compelling.
>>
>> Sounding natural sounds nice but IMO isn't a great argument.
>> What's the ratio of contains()'s to find()'s in your code?
>> In mine find() (or a wrapper of it) is far more common than contains().
>
>
>  $ git grep -E '\.(find|constFind)\(' -- \*.cpp \*.h | wc -l
> 553
>  $ git grep -E '\.contains\(' -- \*.cpp \*.h | wc -l
> 2977

Yes, but in Qt (at least, with applications I've written with Qt
containers), it's common to have code like:

  if (container.contains(key))
    ... container[key] ...

....which would be more efficiently accomplished like:

  if (auto&& iter = container.find(key))
    ... iter.value() ...

IOW, use contains() to see if the value exists, and then one of value(),
at(), operator[](), etc. to *look up the value a second time* and then
do something with it. Whereas find() is normally used only when one
explicitly needs the iterator (which, in fact, with Qt containers, I
wonder why you ever really need to use find()...).

It would therefore be interesting to know how many of those contains()
instances are followed by a second look-up of on the key.

That said, I suspect the above numbers are skewed, since find() occurs
in other contexts (QString::find(), QWidget::find(), etc.) that aren't
container searches, i.e. the "true" number is actually lower. (That
said, there are also QRect::contains(), etc. which throw off the other
number as well.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-12-29 12:37, Thiago Macieira wrote:
> On Monday 29 December 2014 12:12:07 Matthew Woehlke wrote:
>> Yes, but in Qt (at least, with applications I've written with Qt
>> containers), it's common to have code like:
>>
>>   if (container.contains(key))
>>     ... container[key] ...
>>
>> ...which would be more efficiently accomplished like:
>>
>>   if (auto&& iter = container.find(key))
>>     ... iter.value() ...
>>
>> IOW, use contains() to see if the value exists, and then one of value(),
>> at(), operator[](), etc. to *look up the value a second time* and then
>> do something with it. Whereas find() is normally used only when one
>> explicitly needs the iterator (which, in fact, with Qt containers, I
>> wonder why you ever really need to use find()...).
>
> I agree that it would be better, but I can't confirm that it's common.
>
> Random sampling of those 3k matches shows very few of those. For example, I
> found:
>
>     if (d->intHash.contains(sender))
>         emit mapped(d->intHash.value(sender));
>     if (d->stringHash.contains(sender))
>         emit mapped(d->stringHash.value(sender));
>     if (d->widgetHash.contains(sender))
>         emit mapped(d->widgetHash.value(sender));
>     if (d->objectHash.contains(sender))
>         emit mapped(d->objectHash.value(sender));
>
> Which is indeed bad, but those are far from the common case.
>
> Another case I've found is the checking if an element is present in a
> container before inserting it. That indicates we need a new method to "insert
> if not present" and the find method would not have helped.

Yes, that might be useful. (In theory one can use lower_bound and use
the result as an insertion hint, but that's pretty clunky.) In this
case, contains() is maybe less bad. I'll note however that I found such
an example in my own code where additional work needs to be done prior
to insertion; a simple 'insert this value if there wasn't one already'
wouldn't help here. (I also found a few that could use such a method,
however.)

Oh... and contains() for std::set is much more interesting (since of
course there is no value in that case).

Still, a method that returned a checked iterator that implicitly
converts to bool does everything that contains() does, likely at similar
cost, *and* if you subsequently want the value (or iterator), you
already have it.

>> It would therefore be interesting to know how many of those contains()
>> instances are followed by a second look-up of on the key.
>
> Very few.

That's surprising. I looked at some of my own code using Qt, and I
definitely see more than "very few" instances of 'if (c.contains(k)) ...
c[k] ...'. Maybe not half, but probably around a fourth or third.

I also saw at least one case of 'if (c.contains(k) && c[k] ...)', which
I don't see a way to avoid except to have an externally scoped iterator.
(There was some talk of changing the language to be more friendly to
this sort of thing, but I don't think it went anywhere, not unexpectedly.)

>> That said, I suspect the above numbers are skewed, since find() occurs
>> in other contexts (QString::find(), QWidget::find(), etc.) that aren't
>> container searches, i.e. the "true" number is actually lower. (That
>> said, there are also QRect::contains(), etc. which throw off the other
>> number as well.)
>
> QString is a container, so it's a valid match. It's not easy to do a full
> match due to -fvisibility-inlines-hidden.

It really isn't the same, since the result of QString::find() is
effectively already a checked iterator (specifically, an index into the
string with a well known value representing 'no match' and no need to
call end()). The question is if the usage patterns are similar enough to
warrant inclusion in a frequency comparison of find() vs. contains().
(On further thought, they *may* be, but I'd still be interested in
seeing numbers only for QList/QHash/QMap/etc.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-12-29 13:17, Olaf van der Spek wrote:
> On Mon, Dec 29, 2014 at 6:37 PM, Thiago Macieira wrote:
>> [...]
>
> Are you a QT dev?

Really? ;-) Thiago is one of the *major* Qt developers :-). (I don't
know if Qt has "primary" developers as such, but if so I'd suspect
Thiago is in that list. I think he's also one of the *original*
developers; at least, he worked for Trolltech - the company that created
Qt - back when there was such an entity.)

>> Another case I've found is the checking if an element is present in a
>> container before inserting it. That indicates we need a new method to "insert
>> if not present" and the find method would not have helped.
>
> The find method can easily be used as a contains method. How would it
> not have helped?

....because Qt already has contains() :-). An invalid iterator is not
useful for an insertion. (See also my reply.)

>> QString is a container, so it's a valid match. It's not easy to do a full
>> match due to -fvisibility-inlines-hidden.
>
> But it's not the traditional one-element find, would it work with a
> generic contains?

No (not the substring match anyway). The character match might. A string
as a container is a container of characters. If you look at it like a
vector<char> (QChar, in case of QString, but same principles apply to
std::string), contains(string, some_char) makes sense and can be
implemented with a generic algorithm, but I don't see how
contains(string, substring) could work.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5807_912690017.1419878714973
Content-Type: multipart/alternative;
 boundary="----=_Part_5808_105425198.1419878714973"

------=_Part_5808_105425198.1419878714973
Content-Type: text/plain; charset=UTF-8



On Monday, December 29, 2014 10:27:51 PM UTC+4, Matthew Woehlke wrote:
>
> On 2014-12-29 12:37, Thiago Macieira wrote:
> > On Monday 29 December 2014 12:12:07 Matthew Woehlke wrote:
>
> Still, a method that returned a checked iterator that implicitly
> converts to bool does everything that contains() does, likely at similar
> cost, *and* if you subsequently want the value (or iterator), you
> already have it.
>

Wouldn't it introduce surprising behavior?

Leo

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5808_105425198.1419878714973
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br><br>On Monday, December 29, 2014 10:27:51 PM UTC+4, Matthew Woehlke wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-12-29 12:37, Thiago Macieira wrote:
<br>&gt; On Monday 29 December 2014 12:12:07 Matthew Woehlke wrote:
<br><br>Still, a method that returned a checked iterator that implicitly
<br>converts to bool does everything that contains() does, likely at similar
<br>cost, *and* if you subsequently want the value (or iterator), you
<br>already have it.
<br></blockquote><div><br></div><div>Wouldn't it introduce surprising behavior?</div><div><br></div><div>Leo</div></div>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_5808_105425198.1419878714973--
------=_Part_5807_912690017.1419878714973--

.

On 2014-12-29 13:45, Leo Heinsaar wrote:
> On Monday, December 29, 2014 10:27:51 PM UTC+4, Matthew Woehlke wrote:
>> Still, a method that returned a checked iterator that implicitly
>> converts to bool does everything that contains() does, likely at similar
>> cost, *and* if you subsequently want the value (or iterator), you
>> already have it.
>
> Wouldn't it introduce surprising behavior?

Eh? Surprising how?

I can't think what behavior would be introduced that would be
surprising; can you please elaborate?

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_550_1799344585.1419880632214
Content-Type: multipart/alternative;
 boundary="----=_Part_551_719723041.1419880632214"

------=_Part_551_719723041.1419880632214
Content-Type: text/plain; charset=UTF-8

On Monday, December 29, 2014 10:57:01 PM UTC+4, Matthew Woehlke wrote:
>
> On 2014-12-29 13:45, Leo Heinsaar wrote:
> > On Monday, December 29, 2014 10:27:51 PM UTC+4, Matthew Woehlke wrote:
> >> Still, a method that returned a checked iterator that implicitly
> >> converts to bool does everything that contains() does, likely at
> similar
> >> cost, *and* if you subsequently want the value (or iterator), you
> >> already have it.
> >
> > Wouldn't it introduce surprising behavior?
>
> Eh? Surprising how?
>
> I can't think what behavior would be introduced that would be
> surprising; can you please elaborate?
>

On a general note: once we convert something to bool, there is no stopping
it from interacting with other fundamental types from short to double. Just
seems that for iterators, that might introduce unnecessary type-safety bugs.

Leo

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_551_719723041.1419880632214
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, December 29, 2014 10:57:01 PM UTC+4, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-12-29 13:4=
5, Leo Heinsaar wrote:
<br>&gt; On Monday, December 29, 2014 10:27:51 PM UTC+4, Matthew Woehlke wr=
ote:
<br>&gt;&gt; Still, a method that returned a checked iterator that implicit=
ly=20
<br>&gt;&gt; converts to bool does everything that contains() does, likely =
at similar=20
<br>&gt;&gt; cost, *and* if you subsequently want the value (or iterator), =
you=20
<br>&gt;&gt; already have it.=20
<br>&gt;=20
<br>&gt; Wouldn't it introduce surprising behavior?
<br>
<br>Eh? Surprising how?
<br>
<br>I can't think what behavior would be introduced that would be
<br>surprising; can you please elaborate?
<br></blockquote><div><br></div><div>On a general note: once we convert som=
ething to bool, there is no stopping it from interacting with other fundame=
ntal types from short to double. Just seems that for iterators, that might =
introduce unnecessary type-safety bugs.</div><div><br></div><div>Leo</div><=
/div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_551_719723041.1419880632214--
------=_Part_550_1799344585.1419880632214--

.

On 2014-12-29 14:34, Leo Heinsaar wrote:
> On Monday, December 29, 2014 11:26:52 PM UTC+4, Olaf van der Spek wrote:
>> That's why we've got explicit operator bool.
>
> Well, originally, at least, Matthew wrote: "Maybe we could instead create a
> form of ::find() that returns an optional<iterator> or checked_iterator or
> similar, that can be *implicitly* cast to bool to test for validity."

Bah. Sorry. Please forgive my sloppiness with the technical pedantics :-).

What I mean was, I must be able to write 'if(auto iter = ...)'. As long
as the bool conversion works in this context, all is well. That's what I
meant by "implicit" (i.e. natural language usage), not that the operator
should be non-explicit (which I think/hope it can be, even in the above
context).

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-12-25 01:40, Leo Heinsaar wrote:
> Range-for and auto greatly simplify code dealing with iterators - thanks to
> all who contributed to that - but don't you think it's an omission we still
> don't have the very simple *bool* *contains(const T&)* family in STL
> containers?
>
> There's hardly a single production codebase in the world that doesn't have
> the contains() boilerplate (I mean, of course, comparing the result of
> find() to an end() to see if the value is there), often in multiple places.
> And I guess range-for and auto were also at least partly born out of
> realization that our code often deserves a higher abstraction level than
> iterators.

On a related note, another action that is highly useful (also Qt
inspired) is the ::value(KeyType key, ValueType defaultValue = {})
method, which returns the value at Key if present, otherwise
defaultValue (*WITHOUT* inserting a value as operator[] would do).

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_6596_337226598.1419928738786
Content-Type: multipart/alternative;
 boundary="----=_Part_6597_558088153.1419928738786"

------=_Part_6597_558088153.1419928738786
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 30, 2014 2:01:07 AM UTC+4, Matthew Woehlke wrote:
>
> On 2014-12-25 01:40, Leo Heinsaar wrote:
> > Range-for and auto greatly simplify code dealing with iterators - thanks
> to
> > all who contributed to that - but don't you think it's an omission we
> still
> > don't have the very simple *bool* *contains(const T&)* family in STL
> > containers?
> >
> > There's hardly a single production codebase in the world that doesn't
> have
> > the contains() boilerplate (I mean, of course, comparing the result of
> > find() to an end() to see if the value is there), often in multiple
> places.
> > And I guess range-for and auto were also at least partly born out of
> > realization that our code often deserves a higher abstraction level than
> > iterators.
>
> On a related note, another action that is highly useful (also Qt
> inspired) is the ::value(KeyType key, ValueType defaultValue = {})
> method, which returns the value at Key if present, otherwise
> defaultValue (*WITHOUT* inserting a value as operator[] would do).
>

Actually I came to the need for *contains()* from the point of view of a
frustrated engineer rather than an inspired artist (to my shame, I didn't
know that Qt's containers have *contains()* - which all the more reinforces
the need for a *bool contains(const T&)*, I guess.)

Leo

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6597_558088153.1419928738786
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, December 30, 2014 2:01:07 AM UTC+4, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-12-25 01:4=
0, Leo Heinsaar wrote:
<br>&gt; Range-for and auto greatly simplify code dealing with iterators - =
thanks to=20
<br>&gt; all who contributed to that - but don't you think it's an omission=
 we still=20
<br>&gt; don't have the very simple *bool* *contains(const T&amp;)* family =
in STL=20
<br>&gt; containers?
<br>&gt;=20
<br>&gt; There's hardly a single production codebase in the world that does=
n't have=20
<br>&gt; the contains() boilerplate (I mean, of course, comparing the resul=
t of=20
<br>&gt; find() to an end() to see if the value is there), often in multipl=
e places.=20
<br>&gt; And I guess range-for and auto were also at least partly born out =
of=20
<br>&gt; realization that our code often deserves a higher abstraction leve=
l than=20
<br>&gt; iterators.
<br>
<br>On a related note, another action that is highly useful (also Qt
<br>inspired) is the ::value(KeyType key, ValueType defaultValue =3D {})
<br>method, which returns the value at Key if present, otherwise
<br>defaultValue (*WITHOUT* inserting a value as operator[] would do).<br><=
/blockquote><div><br></div><div>Actually I came to the need for&nbsp;<b>con=
tains()</b> from the point of view of a frustrated engineer rather than an =
inspired artist (to my shame, I didn't know that Qt's containers have <b>co=
ntains()</b> - which all the more reinforces the need for a <b>bool contain=
s(const T&amp;)</b>, I guess.)</div><div><br></div><div>Leo&nbsp;</div></di=
v>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6597_558088153.1419928738786--
------=_Part_6596_337226598.1419928738786--

.

On 2014-12-29 23:56, Reza Jahanbakhshi wrote:
>>> auto it = lower_bound(container.begin(), container.end(), value);
>>> if (it == container.end() || *it != value)
>>>     container.insert(it, value);
>>
>> You're doing this for a sequential container in sorted order. That
>> will not apply to a sequential container with appending at the end
>> nor will it work for an associative container. Think of a hashing
>> table.
>
> The only requirement is that the iterator range should be sorted. For
> sorted sequential containers like vector, it works even when appending at
> the end. And for unsorted sequential containers the question is whether it
> is correct to use them this way or not.

This can't be used with e.g. std::unordered_map (or QHash). From an
efficiency standpoint, if the container had an 'insert_missing' method,
it would only need to compute the hash and find the appropriate bin
once, which would be an improvement (a small one perhaps, but still an
improvement).

Even with e.g. std::map, such a method would be a LOT less typing :-).

> Please note that because std::pair doesn't have an equality check operator
> the above code should be tweaked to be used for map and unrodered_map but
> the general idea still applies.

....which reminds me, std::map requiring the user to use std::pair is
another thing I hate about STL containers :-). IMO Qt got this right;
the insert method takes two parameters, i.e. the key and the value.

(Is there any reason we couldn't add this as an overload?)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_500_1913595920.1419964104803
Content-Type: multipart/alternative;
 boundary="----=_Part_501_1091529968.1419964104804"

------=_Part_501_1091529968.1419964104804
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 30, 2014 5:30:44 PM UTC+1, Matthew Woehlke wrote:
>
>
> ...which reminds me, std::map requiring the user to use std::pair is
> another thing I hate about STL containers :-). IMO Qt got this right;
> the insert method takes two parameters, i.e. the key and the value.
>
> (Is there any reason we couldn't add this as an overload?)


Doesn't emplace() do just that?

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_501_1091529968.1419964104804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, December 30, 2014 5:30:44 PM UTC+1, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>...which remin=
ds me, std::map requiring the user to use std::pair is
<br>another thing I hate about STL containers :-). IMO Qt got this right;
<br>the insert method takes two parameters, i.e. the key and the value.
<br>
<br>(Is there any reason we couldn't add this as an overload?)
</blockquote><div><br></div><div><span style=3D"font-size: 13px;">Doesn't e=
mplace() do just that?<br><br>Kind regards,<br><br>Andy</span></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_501_1091529968.1419964104804--
------=_Part_500_1913595920.1419964104803--

.

------=_Part_104_326562324.1419964305944
Content-Type: multipart/alternative;
 boundary="----=_Part_105_1712261383.1419964305944"

------=_Part_105_1712261383.1419964305944
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 30, 2014 7:28:24 PM UTC+1, Andy Prowl wrote:
>
>
> Doesn't emplace() do just that?
>
>
Hm, I just realized it technically doesn't, because emplace() a variadic
function template and not a function taking *two* arguments with a specific
type, but it does allow providing the key and the value as separate
arguments without the need to call std::make_pair().

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_105_1712261383.1419964305944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, December 30, 2014 7:28:24 PM UTC+1, Andy Prowl=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
br></div><div><span style=3D"font-size:13px">Doesn't emplace() do just that=
?<br><br></span></div></div></blockquote><div><br></div><div>Hm, I just rea=
lized it technically doesn't, because emplace() a variadic function templat=
e and not a function taking *two* arguments with a specific type, but it do=
es allow providing the key and the value as separate arguments without the =
need to call std::make_pair().<br><br>Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_105_1712261383.1419964305944--
------=_Part_104_326562324.1419964305944--

.

(Sorry if this double-posts; I'm re-sending as I believe gmane ate my
first attempt.)

On 2014-12-30 13:28, Andy Prowl wrote:
> On Tuesday, December 30, 2014 5:30:44 PM UTC+1, Matthew Woehlke wrote:
>> ...which reminds me, std::map requiring the user to use std::pair is=20
>> another thing I hate about STL containers :-). IMO Qt got this right;=20
>> the insert method takes two parameters, i.e. the key and the value.=20
>>
>> (Is there any reason we couldn't add this as an overload?)=20
>=20
> Doesn't emplace() do just that?

I didn't realize std::map *had* an emplace... it's a bit odd for
std::map, because you can't actually use it to construct the key or
value types, the way emplace works for e.g. std::vector.

In fact, I fail to see why it's even variadic... how is
std::map::emplace anything but a shortcut for the appropriate
std::make_pair? Is there any reason why it shouldn't specify the actual
key and value types? (I'll further note that it appears that, despite
being variadic, things break anyway if it isn't given exactly two
arguments, at least in the libstdc++ implementation.)

That said... no, it doesn't. At least on gcc 4.8.3, emplace isn't nearly
as useful as an insert/emplace taking the explicit argument types, as I
can't use brace initialization to construct the key/value. (Implicit
conversions do work, but then, I think those work with inserting
std::pair of the pre-conversion types also, so there is no improvement
there.)

With Qt (e.g. QHash, but same with QMap), I can do this:

  QHash<int, QPoint> hash;
  hash.insert(5, {1, 2});

Similar code using STL and emplace does not compile.

(=C2=B9 contains(), as previously mentioned, is another)

--=20
Matthew

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-12-30 13:34, Nevin Liber wrote:
> On 30 December 2014 at 11:28, Andy Prowl wrote:
>> On Tuesday, December 30, 2014 5:30:44 PM UTC+1, Matthew Woehlke wrote:
>>> ...which reminds me, std::map requiring the user to use std::pair is
>>> another thing I hate about STL containers :-). IMO Qt got this right;
>>> the insert method takes two parameters, i.e. the key and the value.
>>>
>>> (Is there any reason we couldn't add this as an overload?)
>>
>> Doesn't emplace() do just that?
>
> Shhhh; it is much more fun watching people argue for a feature they claim
> (a) they absolutely have to have

Obviously I don't *have* to have it, it's just much more convenient than
what I'm currently stuck with.

> (b) which the standard already has and

Alas, not in this case, sorry. See my reply to Andy.

> (c) they obviously never use.

Unfortunately I can't even use C++11 on many of the projects I work on,
as we still need to support much older compilers. So cut me a little
slack instead of being a jerk, eh?

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_6304_609227051.1420106483244
Content-Type: multipart/alternative;
 boundary="----=_Part_6305_77017261.1420106483244"

------=_Part_6305_77017261.1420106483244
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 30, 2014 9:39:38 PM UTC+1, Matthew Woehlke wrote:
>
>
> I didn't realize std::map *had* an emplace... it's a bit odd for
> std::map, because you can't actually use it to construct the key or
> value types, the way emplace works for e.g. std::vector.
>

Actually, you can. std::pair takes a constructor which accepts an
std::piecewise_construct and two tuples. It then constructs the pair by
forwarding the arguments in the first tuple to the first element's
constructor, and the arguments in the second tuple to the second element's
constructor. This constructor is a variadic template.

auto p = pair<X, Y>{piecewise_construct, forward_as_tuple(1, 42.0),
forward_as_tuple("hello", "world")};

This is useful if you want to have a pair of non-movable objects.


> In fact, I fail to see why it's even variadic... how is
> std::map::emplace anything but a shortcut for the appropriate
> std::make_pair?


I'm convinced the reason is to support the above-mentioned piecewise
construction, which allows you holding non-movable types in a map. However,
I am not sure why there could not be two overloads of emplace(), a regular
one taking a key and a value, and a variadic template one for piecewise
construction. Perhaps things were easier to formalize this way - with the
EmplaceConstructible concept etc. - or perhaps it is just an oversight. It
is also possible that people thought that supporting brace-initialization
would not be so important here.


> That said... no, it doesn't. At least on gcc 4.8.3, emplace isn't nearly
> as useful as an insert/emplace taking the explicit argument types, as I
> can't use brace initialization to construct the key/value. (Implicit
> conversions do work, but then, I think those work with inserting
> std::pair of the pre-conversion types also, so there is no improvement
> there.)
>

True, although if your types are movable, you can use insert() with
brace-initialization, since the constructor of std::pair is implicit:

struct X
{
    X(int, double, char) { }
};

int main()
{
    auto m = std::map<std::string, X>{};

    m.insert({"Hello", {42, 3.14, 'c'}});
}

Kind regards,

Andy

>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_6305_77017261.1420106483244
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, December 30, 2014 9:39:38 PM UTC+1, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>I didn't reali=
ze std::map *had* an emplace... it's a bit odd for
<br>std::map, because you can't actually use it to construct the key or
<br>value types, the way emplace works for e.g. std::vector.
<br></blockquote><div><br>Actually, you can. std::pair takes a constructor =
which accepts an std::piecewise_construct and two tuples. It then construct=
s the pair by forwarding the arguments in the first tuple to the first elem=
ent's constructor, and the arguments in the second tuple to the second elem=
ent's constructor. This constructor is a variadic template.<br><br><div cla=
ss=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap=
: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> p </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
pair</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">X</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> Y</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">piecewise_construct</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> forward_as_tuple</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">42.0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> forward=
_as_tuple</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"hello"</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #080;" class=3D"styled-by-prettify">"world"</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)};</span></div></code></div><br>T=
his is useful if you want to have a pair of non-movable objects.<br>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">In fact, I fail to see wh=
y it's even variadic... how is
<br>std::map::emplace anything but a shortcut for the appropriate
<br>std::make_pair? </blockquote><div><br>I'm convinced the reason is to su=
pport the above-mentioned piecewise construction, which allows you holding =
non-movable types in a map. However, I am not sure why there could not be t=
wo overloads of emplace(), a regular one taking a key and a value, and a va=
riadic template one for piecewise construction. Perhaps things were easier =
to formalize this way - with the EmplaceConstructible concept etc. - or per=
haps it is just an oversight. It is also possible that people thought that =
supporting brace-initialization would not be so important here.<br>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">That said... no, it doesn'=
t. At least on gcc 4.8.3, emplace isn't nearly
<br>as useful as an insert/emplace taking the explicit argument types, as I
<br>can't use brace initialization to construct the key/value. (Implicit
<br>conversions do work, but then, I think those work with inserting
<br>std::pair of the pre-conversion types also, so there is no improvement
<br>there.)
<br></blockquote><div><br>True, although if your types are movable, you can=
 use insert() with brace-initialization, since the constructor of std::pair=
 is implicit:<br><br><div class=3D"prettyprint" style=3D"border: 1px solid =
rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, =
250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> X<br></span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; X</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">double</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> m </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">map</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> X</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;{};</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; <br>&nbsp; &nbsp; m</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">insert</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">({</span><span style=3D"color: #=
080;" class=3D"styled-by-prettify">"Hello"</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">42</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">3.14</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">'c'</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}});</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">}</span></div></code></div><div><br>Kind regards,<br><br>Andy</=
div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br></blockquote></d=
iv>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6305_77017261.1420106483244--
------=_Part_6304_609227051.1420106483244--

.

------=_Part_8307_1499381639.1420109720062
Content-Type: multipart/alternative;
 boundary="----=_Part_8308_1534092775.1420109720062"

------=_Part_8308_1534092775.1420109720062
Content-Type: text/plain; charset=UTF-8

Just to sum things up a bit and avoid divergence, I think the main
objections I've seen or thought of so far to having a free-function
std::contains(c, elem) algorithm are:

1. The syntax c.contains(elem) would be more readable and typer-friendly
(auto-completion);
2. A find(c, elem) returning a checked iterator would generalize
std::contains() and allow retrieving the element later, if necessary;
3. Current standard algorithms work with pairs of iterators, not with
ranges: rather than std::contains(c, elem), it would have to be
std::contains(b, e, elem). Is it all worth it now that ranges are likely to
become a thing?

Point 1 is a non-argument IMO, possibly thanks to UFCS proposal, but also
because I don't think saving keystrokes *per se* is a sensible goal.

Point 2 makes sense, but although I agree that having a contains() followed
by a find() would be a bad thing and users (especially neophytes) may be
led to write such code, I also think that this is an easy-to-avoid
premature pessimization if users know their algorithms (which they should),
that the code can be easily rewritten to use only a find(), and that
profilers (or even static analyzers?) should allow spotting these
pessimizations.
Using checked iterators as suggested by Matthew would work, but I see a few
issues with that:

 a) The proposed idiomatic usage is more complex and therefore harder to
teach, involving explicit conversions of iterators to bool and binding of
rvalue references to temporaries;
 b) Introducing declarations inside an "if" statement's test is (at least
IMO) not a good candidate for an idiom, because the conditional here does
two things: testing a condition and introducing a new variable. This seems
to violate SRP and make code harder to understand;
 c) The type of iterator returned by find() would have to be different from
the types of iterators returned by other algorithms and/or begin()/end()
functions. What would be the type of this iterator, and how would it
interact with the other types? And is it really not going to introduce any
performance or memory overhead over - say - just using pointers used as RA
iterators?
 d) As pointed out by Leo, the situation is not much different from the one
of having both std::binary_search() and std::lower_bound(). If that was
justifiable, why isn't it to have std::contains() returning a bool?

Objections a) and b) above are admittedly subjective, but it seems to me
addressing objection c) would require an excessive amount of
standardization work, considering that the problem we intend to solve is as
simple as the lack of a "contains" algorithm. I think objection d) is also
quite a valid consistency argument.

I think the last point (Point 3) from the beginning of this message calls
for some deeper consideration: an std::contains() algorithm taking a
container and an element would only make sense in the context of the Range
proposal, because current algorithms all take pairs of iterators. Do we
want to have an std::contains() that takes pairs of iterators too, for
consistency (or in the hopefully unlikely case that Ranges won't make it to
the next Standard)? But wouldn't that carry most of the syntactic overhead
of std::find(), forcing users to write their own contains() anyway to avoid
the "begin(c), end(c)" noise? At that point, adding "!= end(c)" to their
contains() wrapper would change nothing from a usage perspective. This
seems to suggest that the introduction of std::contains() should be
addressed by the Range proposal.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_8308_1534092775.1420109720062
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just to sum things up a bit and avoid divergence, I think =
the main objections I've seen or thought of&nbsp;<span style=3D"font-size: =
13.3333330154419px;">so far&nbsp;</span>to having a free-function std::cont=
ains(c, elem)&nbsp;algorithm are:<br><br>1. The syntax c.contains(elem) wou=
ld be more readable and typer-friendly (auto-completion);&nbsp;<br>2. A fin=
d(c, elem) returning a checked iterator would generalize std::contains() an=
d allow retrieving the element later, if necessary;<br>3. Current standard =
algorithms work with pairs of iterators, not with ranges: rather than std::=
contains(c, elem), it would have to be std::contains(b, e, elem). Is it all=
 worth it now that ranges are likely to become a thing?<br><br><span style=
=3D"font-size: 13.3333330154419px;">Point 1 is a non-argument IMO, possibly=
 thanks to UFCS proposal, but also because I don't think saving keystrokes =
<i>per se</i> is a sensible goal.<br></span><br>Point 2 makes sense, but al=
though I agree that having a contains() followed by a find() would be a bad=
 thing and users (especially neophytes) may be led to write such code, I al=
so think that this is an easy-to-avoid premature pessimization if users kno=
w their algorithms (which they should), that the code can be easily rewritt=
en to use only a find(), and that profilers (or even static analyzers?) sho=
uld allow spotting these pessimizations.<br>Using checked iterators as sugg=
ested by Matthew would work, but I see a few issues with that:<br><br>&nbsp=
;a) The proposed idiomatic usage is more complex and therefore harder to te=
ach, involving explicit conversions of iterators to bool and binding of rva=
lue references to temporaries;<br>&nbsp;b) Introducing declarations inside =
an "if" statement's test is (at least IMO) not a good candidate for an idio=
m, because the conditional here does two things: testing a condition and in=
troducing a new variable. This seems to violate SRP and make code harder to=
 understand;<br>&nbsp;c) The type of iterator returned by find() would have=
 to be different from the types of iterators returned by other algorithms a=
nd/or begin()/end() functions. What would be the type of this iterator, and=
 how would it interact with the other types? And is it really not going to =
introduce any performance or memory overhead over - say - just using pointe=
rs used as RA iterators?<br>&nbsp;d) As pointed out by Leo, the situation i=
s not much different from the one of having both std::binary_search() and s=
td::lower_bound(). If that was justifiable, why isn't it to have std::conta=
ins() returning a bool?<br><br>Objections a) and b) above are admittedly su=
bjective, but it seems to me addressing objection c) would require an exces=
sive amount of standardization work, considering that the problem we intend=
 to solve is as simple as the lack of a "contains" algorithm. I think objec=
tion d) is also quite a valid&nbsp;<span style=3D"font-size: 13.33333301544=
19px;">consistency&nbsp;</span>argument.<br><br>I think the last point (Poi=
nt 3) from the beginning of this message calls for some deeper consideratio=
n: an std::contains() algorithm taking a container and an element would onl=
y make sense in the context of the Range proposal, because current algorith=
ms all take pairs of iterators. Do we want to have an std::contains() that =
takes pairs of iterators too, for consistency (or in the hopefully unlikely=
 case that Ranges won't make it to the next Standard)? But wouldn't that ca=
rry most of the syntactic overhead of std::find(), forcing users to write t=
heir own contains() anyway to avoid the "begin(c), end(c)" noise? At that p=
oint, adding "!=3D end(c)" to their contains() wrapper would change nothing=
 from a usage perspective. This seems to suggest that the introduction of s=
td::contains() should be addressed by the Range proposal.<br><br>Kind regar=
ds,<br><br>Andy</div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8308_1534092775.1420109720062--
------=_Part_8307_1499381639.1420109720062--

.

On 2015-01-01 05:55, Andy Prowl wrote:
> Using checked iterators as suggested by Matthew would work, but I see a few
> issues with that:
>
>  a) The proposed idiomatic usage is more complex and therefore harder to
> teach, involving explicit conversions of iterators to bool and binding of
> rvalue references to temporaries;

Eh? Why does this involve binding an rvalue reference to a temporary? I
don't see how a checked iterator is any different from a regular
iterator (besides the addition of the iterator itself knowing if it is
valid).

For that matter, considering the parallel with pointers, why is
understanding that 'if(iter)'  is equivalent to 'if(is_valid(iter))' for
some definition of is_valid?

>  b) Introducing declarations inside an "if" statement's test is (at least
> IMO) not a good candidate for an idiom, because the conditional here does
> two things: testing a condition and introducing a new variable. This seems
> to violate SRP and make code harder to understand;

To me that's a non-argument, or even an anti-argument. If you don't like
that coding style, don't use it. The purpose however is that the scope
of the iterator is the scope of the if() that checks if the element
exists. That's explicitly one of the features that I *want*.

>  c) The type of iterator returned by find() would have to be different from
> the types of iterators returned by other algorithms and/or begin()/end()
> functions.

True (assuming it is not possible to extend the existing iterators).
Although...

> What would be the type of this iterator, and how would it
> interact with the other types? And is it really not going to introduce any
> performance or memory overhead over - say - just using pointers used as RA
> iterators?

....only for associative containers. At least std::vector would return a
pointer. The difference would be that an invalid iterator, at least for
std::vector, should not be used for insertion, since it will be a
nullptr. (I say "should" because it seems feasible to change the methods
that take "iterators" to treat nullptr as end(), although this may not
be a good idea.)

It *may* need 4 more bytes of memory (plus alignment), but is that
really an issue? We're still talking about something that is very small.

As for behavior, it should be trivial to convert a valid
checked_iterator to a regular iterator (or const_iterator). The result
of trying to convert an invalid iterator could be undefined. (An
iterator equal to end() is almost never useful anyway.)

Much of this depends on deciding if the new iterator has an explicit
validity flag (and therefore is slightly larger), in which case we can
do all sorts of useful things such as defining that an invalid iterator
for ordered associative containers (i.e. map, set) also contains the
last point in the container that was considered (i.e. lower_bound), in
which case even an invalid iterator serves as an insertion hint, or if
its reference into the container is set up in a way so as to be
explicitly invalid, such that it occupies the same space but is useless
if invalid.

I don't feel that these are difficult problems to solve, however.

>  d) As pointed out by Leo, the situation is not much different from the one
> of having both std::binary_search() and std::lower_bound(). If that was
> justifiable, why isn't it to have std::contains() returning a bool?

....why doesn't std::find return a pair<iterator, bool>? :-)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4954_625010925.1420135583400
Content-Type: multipart/alternative;
 boundary="----=_Part_4955_1216098998.1420135583400"

------=_Part_4955_1216098998.1420135583400
Content-Type: text/plain; charset=UTF-8

On Thursday, January 1, 2015 6:19:21 PM UTC+1, Matthew Woehlke wrote:
>
> On 2015-01-01 05:55, Andy Prowl wrote:
> > Using checked iterators as suggested by Matthew would work, but I see a
> few
> > issues with that:
> >
> >  a) The proposed idiomatic usage is more complex and therefore harder to
> > teach, involving explicit conversions of iterators to bool and binding
> of
> > rvalue references to temporaries;
>
> Eh? Why does this involve binding an rvalue reference to a temporary? I
> don't see how a checked iterator is any different from a regular
> iterator (besides the addition of the iterator itself knowing if it is
> valid).
>

I'll answer this together with the next point.


> For that matter, considering the parallel with pointers, why is
> understanding that 'if(iter)'  is equivalent to 'if(is_valid(iter))' for
> some definition of is_valid?
>
> >  b) Introducing declarations inside an "if" statement's test is (at
> least
> > IMO) not a good candidate for an idiom, because the conditional here
> does
> > two things: testing a condition and introducing a new variable. This
> seems
> > to violate SRP and make code harder to understand;
>
> To me that's a non-argument, or even an anti-argument. If you don't like
> that coding style, don't use it. The purpose however is that the scope
> of the iterator is the scope of the if() that checks if the element
> exists. That's explicitly one of the features that I *want*.
>

OK, you might be correct here and as I wrote, this is a subjective
argument. However, if I did not want to use that style, I would write:

auto iter = find(container, element);
if (iter)
{
    // Do stuff with iter...
}

Which is not much of an advantage over:

auto iter = find(container, element);
if (iter != end(container))
{
    // Do stuff with iter...
}

The syntactic significance of the explicit conversion to bool mostly exists
when you adopt the style you suggest; in other words, the feature and the
style are not as orthogonal as it might seem. Anyway, I do realize this is
a subjective argument and I understand you see it differently. What I do
think is objective is that this code:

if (contains(c, elem))
{
    // ...
}

Is more intent-revealing than this code:

if (find(c, elem))
{
    // ...
}

There is hardly any name which is more intent-revealing than "contains"
when it comes to containment of containers. I think this is a fundamental
operation that deserves being a standard algorithm. It could even be
written in terms of a find() algorithm returning a checked iterator, if
checked iterators turn out to be a really good idea: I wouldn't mind. What
I think is not a good idea is to throw away "contains()" because it can be
generalized by a revised "find()".

>  c) The type of iterator returned by find() would have to be different
from

> > the types of iterators returned by other algorithms and/or begin()/end()
> > functions.
>
> True (assuming it is not possible to extend the existing iterators).
> Although...
>
> > What would be the type of this iterator, and how would it
> > interact with the other types? And is it really not going to introduce
> any
> > performance or memory overhead over - say - just using pointers used as
> RA
> > iterators?
>
> ...only for associative containers. At least std::vector would return a
> pointer. The difference would be that an invalid iterator, at least for
> std::vector, should not be used for insertion, since it will be a
> nullptr. (I say "should" because it seems feasible to change the methods
> that take "iterators" to treat nullptr as end(), although this may not
> be a good idea.)
>

Not sure I understand here. Would find(v, elem) have to return nullptr if
elem is not found in vector v? If so, you couldn't get back to the previous
element by decrementing the result, which is something you can do with
regular iterators (not saying it's a good thing to do, yet it does imply
some difference in behavior).


> It *may* need 4 more bytes of memory (plus alignment), but is that
> really an issue? We're still talking about something that is very small.

As for behavior, it should be trivial to convert a valid
> checked_iterator to a regular iterator (or const_iterator). The result
> of trying to convert an invalid iterator could be undefined. (An
> iterator equal to end() is almost never useful anyway.)
>
> Much of this depends on deciding if the new iterator has an explicit
> validity flag (and therefore is slightly larger), in which case we can
> do all sorts of useful things such as defining that an invalid iterator
> for ordered associative containers (i.e. map, set) also contains the
> last point in the container that was considered (i.e. lower_bound), in
> which case even an invalid iterator serves as an insertion hint, or if
> its reference into the container is set up in a way so as to be
> explicitly invalid, such that it occupies the same space but is useless
> if invalid.
>
> I don't feel that these are difficult problems to solve, however.
>

Maybe. But considering the amount of discussion that something as simple as
"contains()" triggered, I'd expect people will have different opinions on
*how* to solve the problem, possibly finding several subtle implications.
Again, I might be wrong, but this looks like the amount of work is not
worth it.


> >  d) As pointed out by Leo, the situation is not much different from the
> one
> > of having both std::binary_search() and std::lower_bound(). If that was
> > justifiable, why isn't it to have std::contains() returning a bool?
>
> ...why doesn't std::find return a pair<iterator, bool>? :-)
>

Why should it? That's what insert() returns for associative containers, not
find() - forgive if I failed to get the analogy :)

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4955_1216098998.1420135583400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, January 1, 2015 6:19:21 PM UTC+1, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-01-01 05:55=
, Andy Prowl wrote:
<br>&gt; Using checked iterators as suggested by Matthew would work, but I =
see a few=20
<br>&gt; issues with that:
<br>&gt;=20
<br>&gt; &nbsp;a) The proposed idiomatic usage is more complex and therefor=
e harder to=20
<br>&gt; teach, involving explicit conversions of iterators to bool and bin=
ding of=20
<br>&gt; rvalue references to temporaries;
<br>
<br>Eh? Why does this involve binding an rvalue reference to a temporary? I
<br>don't see how a checked iterator is any different from a regular
<br>iterator (besides the addition of the iterator itself knowing if it is
<br>valid).&nbsp;<br></blockquote><div><br>I'll answer this together with t=
he next point.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
For that matter, considering the parallel with pointers, why is
<br>understanding that 'if(iter)' &nbsp;is equivalent to 'if(is_valid(iter)=
)' for
<br>some definition of is_valid?
<br>
<br>&gt; &nbsp;b) Introducing declarations inside an "if" statement's test =
is (at least=20
<br>&gt; IMO) not a good candidate for an idiom, because the conditional he=
re does=20
<br>&gt; two things: testing a condition and introducing a new variable. Th=
is seems=20
<br>&gt; to violate SRP and make code harder to understand;
<br>
<br>To me that's a non-argument, or even an anti-argument. If you don't lik=
e
<br>that coding style, don't use it. The purpose however is that the scope
<br>of the iterator is the scope of the if() that checks if the element
<br>exists. That's explicitly one of the features that I *want*.
<br></blockquote><div><br>OK, you might be correct here and as I wrote, thi=
s is a subjective argument. However, if I did not want to use that style, I=
 would write:<br><br></div><div class=3D"prettyprint" style=3D"border: 1px =
solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250,=
 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> iter </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> find</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">container</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> element</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
f</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">iter</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// Do stuff with iter...</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span></div></code></div><div><br>Which=
 is not much of an advantage over:<br>&nbsp;<br><div class=3D"prettyprint" =
style=3D"border: 1px solid rgb(187, 187, 187); font-size: 13.3333330154419p=
x; word-wrap: break-word; background-color: rgb(250, 250, 250);"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> iter </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> find</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
container</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> element</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">iter </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">!=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">end</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">container</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">))</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Do stuff with iter...</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code=
></div><br>The syntactic significance of the explicit conversion to bool mo=
stly exists when you adopt the style you suggest; in other words, the featu=
re and the style are not as orthogonal as it might seem. Anyway, I do reali=
ze this is a subjective argument and I understand you see it differently.&n=
bsp;What I do think is objective is that this code:<br><br><div class=3D"pr=
ettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">contains</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">c</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> elem</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">))</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// ...</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span></div></code></div><br>Is more intent-revealing than this code:<br=
><br><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 18=
7); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">find</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> elem</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">// ...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span></div></code></div><span style=3D"font-size: 13.3=
333330154419px;"><br></span>There is hardly any name which is more intent-r=
evealing than "contains" when it comes to containment of containers. I thin=
k this is a fundamental operation that deserves being a standard algorithm.=
 It could even be written in terms of a find() algorithm returning a checke=
d iterator, if checked iterators turn out to be a really good idea: I would=
n't mind. What I think is not a good idea is to throw away "contains()" bec=
ause it can be generalized by a revised "find()".<br style=3D"font-size: 13=
..3333330154419px;"><br><span style=3D"font-size: 13px;">&gt; &nbsp;c) The t=
ype of iterator returned by find() would have to be different from&nbsp;</s=
pan><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; the types o=
f iterators returned by other algorithms and/or begin()/end()=20
<br>&gt; functions.
<br>
<br>True (assuming it is not possible to extend the existing iterators).
<br>Although...
<br>
<br>&gt; What would be the type of this iterator, and how would it=20
<br>&gt; interact with the other types? And is it really not going to intro=
duce any=20
<br>&gt; performance or memory overhead over - say - just using pointers us=
ed as RA=20
<br>&gt; iterators?
<br>
<br>...only for associative containers. At least std::vector would return a
<br>pointer. The difference would be that an invalid iterator, at least for
<br>std::vector, should not be used for insertion, since it will be a
<br>nullptr. (I say "should" because it seems feasible to change the method=
s
<br>that take "iterators" to treat nullptr as end(), although this may not
<br>be a good idea.)
<br></blockquote><div><br>Not sure I understand here. Would find(v, elem) h=
ave to return nullptr if elem is not found in vector v? If so, you couldn't=
 get back to the previous element by decrementing the result, which is some=
thing you can do with regular iterators (not saying it's a good thing to do=
, yet it does imply some difference in behavior).</div><div>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">It *may* need 4 more bytes of mem=
ory (plus alignment), but is that
<br>really an issue? We're still talking about something that is very small=
..&nbsp;<span style=3D"font-size: 13px;">&nbsp;</span></blockquote><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">As for behavior, it should be trivial t=
o convert a valid
<br>checked_iterator to a regular iterator (or const_iterator). The result
<br>of trying to convert an invalid iterator could be undefined. (An
<br>iterator equal to end() is almost never useful anyway.)
<br>
<br>Much of this depends on deciding if the new iterator has an explicit
<br>validity flag (and therefore is slightly larger), in which case we can
<br>do all sorts of useful things such as defining that an invalid iterator
<br>for ordered associative containers (i.e. map, set) also contains the
<br>last point in the container that was considered (i.e. lower_bound), in
<br>which case even an invalid iterator serves as an insertion hint, or if
<br>its reference into the container is set up in a way so as to be
<br>explicitly invalid, such that it occupies the same space but is useless
<br>if invalid.
<br>
<br>I don't feel that these are difficult problems to solve, however.
<br></blockquote><div><br>Maybe. But considering the amount of discussion t=
hat something as simple as "contains()" triggered, I'd expect people will h=
ave different opinions on <i>how</i> to solve the problem, possibly finding=
 several subtle implications. Again, I might be wrong, but this looks like =
the amount of work is not worth it.<br>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">&gt; &nbsp;d) As pointed out by Leo, the situation is =
not much different from the one=20
<br>&gt; of having both std::binary_search() and std::lower_bound(). If tha=
t was=20
<br>&gt; justifiable, why isn't it to have std::contains() returning a bool=
?
<br>
<br>...why doesn't std::find return a pair&lt;iterator, bool&gt;? :-)
<br></blockquote><div><br>Why should it? That's what insert() returns for a=
ssociative containers, not find() - forgive if I failed to get the analogy =
:)<br>&nbsp;<br>Kind regards,<br><br>Andy</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4955_1216098998.1420135583400--
------=_Part_4954_625010925.1420135583400--

.

On 2015-01-01 13:06, Andy Prowl wrote:
> On Thursday, January 1, 2015 6:19:21 PM UTC+1, Matthew Woehlke wrote:
>> At least std::vector would return a pointer. The difference would
>> be that an invalid iterator, at least for std::vector, should not
>> be used for insertion, since it will be a nullptr. (I say "should"
>> because it seems feasible to change the methods that take
>> "iterators" to treat nullptr as end(), although this may not be a
>> good idea.)
>
> Not sure I understand here. Would find(v, elem) have to return nullptr if
> elem is not found in vector v? If so, you couldn't get back to the previous
> element by decrementing the result, which is something you can do with
> regular iterators (not saying it's a good thing to do, yet it does imply
> some difference in behavior).

Right. See also where I talked about it being undefined to do anything
with an invalid iterator (besides test its validity, of course).

>> ...why doesn't std::find return a pair<iterator, bool>? :-)
>
> Why should it? That's what insert() returns for associative containers, not
> find() - forgive if I failed to get the analogy :)

(Sorry, I think I must have misread what you wrote and was in fact
thinking of insert(). Still...)

For the same reason that insert does. The objective was to say, if it's
useful for insert(), why is it not useful for find()?

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_28_1850647198.1420139570028
Content-Type: multipart/alternative;
 boundary="----=_Part_29_1821797285.1420139570029"

------=_Part_29_1821797285.1420139570029
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, January 1, 2015 10:06:23 PM UTC+4, Andy Prowl wrote:
>
> On Thursday, January 1, 2015 6:19:21 PM UTC+1, Matthew Woehlke wrote:
>>
>> On 2015-01-01 05:55, Andy Prowl wrote:=20
>
> ...=20

>  What I do think is objective is that this code:
>>
>
> if (contains(c, elem))
> {
>     // ...
> }
>
> Is more intent-revealing than this code:
>
> if (find(c, elem))
> {
>     // ...
> }
>
> There is hardly any name which is more intent-revealing than "contains"=
=20
> when it comes to containment of containers. I think this is a fundamental=
=20
> operation that deserves being a standard algorithm. It could even be=20
> written in terms of a find() algorithm returning a checked iterator, if=
=20
> checked iterators turn out to be a really good idea: I wouldn't mind. Wha=
t=20
> I think is not a good idea is to throw away "contains()" because it can b=
e=20
> generalized by a revised "find()".
>

I couldn't resist emphasizing (again) that I couldn't agree more.

To try to visualize this point, I'd like to say that, to me, not being able=
=20
to have the simplest form of *contains() *for containers is like not having=
=20
the "=E2=88=88" or "=E2=8A=82" symbols in math =E2=80=93 a simple and fast =
way of expressing=20
"containment" and "inclusion" =E2=80=93 IMO it's as fundamental as these tw=
o simple=20
symbols because *contains()* would reveal the intent in exactly the same=20
easy way as "=E2=88=88" does (*x =E2=88=88 X* for a concrete set X is like =
saying=20
*X.contains(x)*). After all, we do have *includes() *standardized, which=20
one can view as the equivalent of "=E2=8A=82".

Leo=20

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_29_1821797285.1420139570029
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, January 1, 2015 10:06:23 PM UTC+4, An=
dy Prowl wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Thursday, January 1, 2015 6:19:21 PM UTC+1, Matthew Woehlke wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">On 2015-01-01 05:55, Andy Prowl wrote:&=
nbsp;</blockquote></div></blockquote><div>...&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">&nbsp;What I do think is objective is that this code:<br></blockq=
uote><div><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:bre=
ak-word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:=
#008">if</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">contains</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#000">c</span><span style=3D"color:#660">,=
</span><span style=3D"color:#000"> elem</span><span style=3D"color:#660">))=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"col=
or:#800">// ...</span><span style=3D"color:#000"><br></span><span style=3D"=
color:#660">}</span></div></code></div><br>Is more intent-revealing than th=
is code:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:b=
reak-word;background-color:rgb(250,250,250)"><code><div><span style=3D"colo=
r:#008">if</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">(</span><span style=3D"color:#000">find</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">c</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> elem</span><span style=3D"color:#660">))</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color=
:#800">// ...</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">}</span></div></code></div><span style=3D"font-size:13.3333330154=
419px"><br></span>There is hardly any name which is more intent-revealing t=
han "contains" when it comes to containment of containers. I think this is =
a fundamental operation that deserves being a standard algorithm. It could =
even be written in terms of a find() algorithm returning a checked iterator=
, if checked iterators turn out to be a really good idea: I wouldn't mind. =
What I think is not a good idea is to throw away "contains()" because it ca=
n be generalized by a revised "find()".<br style=3D"font-size:13.3333330154=
419px"></div></div></blockquote><div><br></div><div>I couldn't resist empha=
sizing (again) that I couldn't agree more.</div><div><br></div><div>To try =
to visualize this point, I'd like to say that, to me, not being able to hav=
e the simplest form of&nbsp;<b>contains()&nbsp;</b>for containers is like n=
ot having the "<span style=3D"color: rgb(17, 17, 17); font-family: MathJax_=
Main; white-space: nowrap; background-color: rgb(254, 254, 254);"><font siz=
e=3D"2">=E2=88=88</font></span>" or "<span style=3D"font-size: small; color=
: rgb(17, 17, 17); font-family: MathJax_Main; white-space: nowrap;">=E2=8A=
=82</span>" symbols in math&nbsp;<span style=3D"color: rgb(84, 84, 84); fon=
t-family: arial, sans-serif; font-size: small; line-height: 18.200000762939=
5px;">=E2=80=93 </span><span style=3D"font-family: arial, sans-serif; font-=
size: small; line-height: 18.2000007629395px;"><font color=3D"#000000">a si=
mple and fast way of expressing "containment" and "inclusion"</font></span>=
&nbsp;<span style=3D"font-size: small; color: rgb(84, 84, 84); font-family:=
 arial, sans-serif; line-height: 18.2000007629395px;">=E2=80=93</span>&nbsp=
;IMO it's as fundamental as these two simple symbols because <b>contains()<=
/b>&nbsp;would reveal the intent in exactly the same easy way as&nbsp;"<spa=
n style=3D"color: rgb(17, 17, 17); font-family: MathJax_Main; white-space: =
nowrap; background-color: rgb(254, 254, 254);"><font size=3D"2">=E2=88=88</=
font></span>"&nbsp;does (<b>x&nbsp;<span style=3D"font-size: small; color: =
rgb(17, 17, 17); font-family: MathJax_Main; white-space: nowrap; background=
-color: rgb(254, 254, 254);">=E2=88=88</span>&nbsp;X</b> for a concrete set=
 X is like saying <b>X.contains(x)</b>). After all, we do have&nbsp;<b>incl=
udes()&nbsp;</b>standardized, which one can view as the equivalent of "<spa=
n style=3D"font-size: small; color: rgb(17, 17, 17); font-family: MathJax_M=
ain; white-space: nowrap;">=E2=8A=82</span>".</div><div><br></div><div>Leo&=
nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_29_1821797285.1420139570029--
------=_Part_28_1850647198.1420139570028--

.

------=_Part_67_2023486649.1420295905828
Content-Type: multipart/alternative;
 boundary="----=_Part_68_1189075851.1420295905828"

------=_Part_68_1189075851.1420295905828
Content-Type: text/plain; charset=UTF-8



On Thursday, January 1, 2015 11:55:20 AM UTC+1, Andy Prowl wrote:
>
>  b) Introducing declarations inside an "if" statement's test is (at least
> IMO) not a good candidate for an idiom, because the conditional here does
> two things: testing a condition and introducing a new variable. This seems
> to violate SRP and make code harder to understand;
>

What's SRP and what's wrong with a combined definition and test? Combining
them is very natural once you've tried it a few times. Not combining them
requires you to repeat the iterator name (and the container name) and the
variable has a bigger scope then it should have.


>  c) The type of iterator returned by find() would have to be different
> from the types of iterators returned by other algorithms and/or
> begin()/end() functions. What would be the type of this iterator, and how
> would it interact with the other types? And is it really not going to
> introduce any performance or memory overhead over - say - just using
> pointers used as RA iterators?
>

Pointers can be used instead of 'checked' iterators. Pointers surely have
no performance or memory overhead. ;)
Obviously you lose the iterator but that's the same for contains().


>  d) As pointed out by Leo, the situation is not much different from the
> one of having both std::binary_search() and std::lower_bound(). If that was
> justifiable, why isn't it to have std::contains() returning a bool?
>
>
AFAIK the return type of binary_search was a mistake.



> Objections a) and b) above are admittedly subjective, but it seems to me
> addressing objection c) would require an excessive amount of
> standardization work, considering that the problem we intend to solve is as
> simple as the lack of a "contains" algorithm. I think objection d) is also
> quite a valid consistency argument.
>
> I think the last point (Point 3) from the beginning of this message calls
> for some deeper consideration: an std::contains() algorithm taking a
> container and an element would only make sense in the context of the Range
> proposal, because current algorithms all take pairs of iterators.
>

IMO a variant taking a range makes sense with or without range proposal.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_68_1189075851.1420295905828
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, January 1, 2015 11:55:20 AM UTC+1, An=
dy Prowl wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">&nbsp;b) Introducing declarations inside an "if" statement's test is (at =
least IMO) not a good candidate for an idiom, because the conditional here =
does two things: testing a condition and introducing a new variable. This s=
eems to violate SRP and make code harder to understand;<br></div></blockquo=
te><div><br></div><div>What's SRP and what's wrong with a combined definiti=
on and test? Combining them is very natural once you've tried it a few time=
s. Not combining them requires you to repeat the iterator name (and the con=
tainer name) and the variable has a bigger scope then it should have.</div>=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">&nbsp;c) The type of iterator returned by find() would have to be diffe=
rent from the types of iterators returned by other algorithms and/or begin(=
)/end() functions. What would be the type of this iterator, and how would i=
t interact with the other types? And is it really not going to introduce an=
y performance or memory overhead over - say - just using pointers used as R=
A iterators?<br></div></blockquote><div><br></div><div>Pointers can be used=
 instead of 'checked' iterators. Pointers surely have no performance or mem=
ory overhead. ;)</div><div>Obviously you lose the iterator but that's the s=
ame for contains().</div><div>&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr">&nbsp;d) As pointed out by Leo, the situation =
is not much different from the one of having both std::binary_search() and =
std::lower_bound(). If that was justifiable, why isn't it to have std::cont=
ains() returning a bool?<br><br></div></blockquote><div>&nbsp;</div><div>AF=
AIK the return type of binary_search was a mistake.</div><div><br></div><di=
v>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Objections a) and b) above are admittedly subjective, but it seems to me a=
ddressing objection c) would require an excessive amount of standardization=
 work, considering that the problem we intend to solve is as simple as the =
lack of a "contains" algorithm. I think objection d) is also quite a valid&=
nbsp;<span style=3D"font-size:13.3333330154419px">consistency&nbsp;</span>a=
rgument.<br><br>I think the last point (Point 3) from the beginning of this=
 message calls for some deeper consideration: an std::contains() algorithm =
taking a container and an element would only make sense in the context of t=
he Range proposal, because current algorithms all take pairs of iterators. =
</div></blockquote><div><br></div><div>IMO a variant taking a range makes s=
ense with or without range proposal.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_68_1189075851.1420295905828--
------=_Part_67_2023486649.1420295905828--

.

------=_Part_1504_1088568128.1420296934316
Content-Type: multipart/alternative;
 boundary="----=_Part_1505_1151338503.1420296934317"

------=_Part_1505_1151338503.1420296934317
Content-Type: text/plain; charset=UTF-8

On Saturday, January 3, 2015 3:38:25 PM UTC+1, Olaf van der Spek wrote:
>
>
>
> On Thursday, January 1, 2015 11:55:20 AM UTC+1, Andy Prowl wrote:
>>
>>  b) Introducing declarations inside an "if" statement's test is (at least
>> IMO) not a good candidate for an idiom, because the conditional here does
>> two things: testing a condition and introducing a new variable. This seems
>> to violate SRP and make code harder to understand;
>>
>
> What's SRP and what's wrong with a combined definition and test? Combining
> them is very natural once you've tried it a few times. Not combining them
> requires you to repeat the iterator name (and the container name) and the
> variable has a bigger scope then it should have.
>

Single Responsibility Principle. As I mentioned, I'm aware this is a
subjective argument :)


>  c) The type of iterator returned by find() would have to be different
>> from the types of iterators returned by other algorithms and/or
>> begin()/end() functions. What would be the type of this iterator, and how
>> would it interact with the other types? And is it really not going to
>> introduce any performance or memory overhead over - say - just using
>> pointers used as RA iterators?
>>
>
> Pointers can be used instead of 'checked' iterators. Pointers surely have
> no performance or memory overhead. ;)
> Obviously you lose the iterator but that's the same for contains().
>

Yes, but contains() is explicitly mean for those cases where the iterator
doesn't matter. I don't think the same can be said of find().


>  d) As pointed out by Leo, the situation is not much different from the
>> one of having both std::binary_search() and std::lower_bound(). If that was
>> justifiable, why isn't it to have std::contains() returning a bool?
>>
>>
> AFAIK the return type of binary_search was a mistake.
>

OK, didn't know that. Can you provide some more background on this?


>
>
>> Objections a) and b) above are admittedly subjective, but it seems to me
>> addressing objection c) would require an excessive amount of
>> standardization work, considering that the problem we intend to solve is as
>> simple as the lack of a "contains" algorithm. I think objection d) is also
>> quite a valid consistency argument.
>>
>> I think the last point (Point 3) from the beginning of this message calls
>> for some deeper consideration: an std::contains() algorithm taking a
>> container and an element would only make sense in the context of the Range
>> proposal, because current algorithms all take pairs of iterators.
>>
>
> IMO a variant taking a range makes sense with or without range proposal.
>

Probably yes, although I'm afraid it would still be inconvenient enough (due
to the begin()/end() noise) for users to opt for a custom wrapper, which
would defeat the purpose.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1505_1151338503.1420296934317
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, January 3, 2015 3:38:25 PM UTC+1, Olaf van de=
r Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>On Thursday, January 1, 2015 11:55:20 AM UTC+1, Andy Prowl wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&nbsp;b) Introducing=
 declarations inside an "if" statement's test is (at least IMO) not a good =
candidate for an idiom, because the conditional here does two things: testi=
ng a condition and introducing a new variable. This seems to violate SRP an=
d make code harder to understand;<br></div></blockquote><div><br></div><div=
>What's SRP and what's wrong with a combined definition and test? Combining=
 them is very natural once you've tried it a few times. Not combining them =
requires you to repeat the iterator name (and the container name) and the v=
ariable has a bigger scope then it should have.</div><div></div></div></blo=
ckquote><div><br>Single Responsibility Principle. As I mentioned, I'm aware=
 this is a subjective argument :)<br>&nbsp;<span style=3D"font-size: 13px;"=
>&nbsp;</span></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&nbsp;c) =
The type of iterator returned by find() would have to be different from the=
 types of iterators returned by other algorithms and/or begin()/end() funct=
ions. What would be the type of this iterator, and how would it interact wi=
th the other types? And is it really not going to introduce any performance=
 or memory overhead over - say - just using pointers used as RA iterators?<=
br></div></blockquote><div><br></div><div>Pointers can be used instead of '=
checked' iterators. Pointers surely have no performance or memory overhead.=
 ;)</div><div>Obviously you lose the iterator but that's the same for conta=
ins().<span style=3D"font-size: 13px;">&nbsp;</span></div></div></blockquot=
e><div><br>Yes, but contains() is explicitly mean for those cases where the=
 iterator doesn't matter. I don't think the same can be said of find().<br>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&nbsp;d) As pointed=
 out by Leo, the situation is not much different from the one of having bot=
h std::binary_search() and std::lower_bound(). If that was justifiable, why=
 isn't it to have std::contains() returning a bool?<br><br></div></blockquo=
te><div>&nbsp;</div><div>AFAIK the return type of binary_search was a mista=
ke.</div></div></blockquote><div><br>OK, didn't know that. Can you provide =
some more background on this?<br>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div></div><div>&nbsp;</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">Objections a) and b) above are ad=
mittedly subjective, but it seems to me addressing objection c) would requi=
re an excessive amount of standardization work, considering that the proble=
m we intend to solve is as simple as the lack of a "contains" algorithm. I =
think objection d) is also quite a valid&nbsp;<span style=3D"font-size:13.3=
333330154419px">consistency&nbsp;</span>argument.<br><br>I think the last p=
oint (Point 3) from the beginning of this message calls for some deeper con=
sideration: an std::contains() algorithm taking a container and an element =
would only make sense in the context of the Range proposal, because current=
 algorithms all take pairs of iterators. </div></blockquote><div><br></div>=
<div>IMO a variant taking a range makes sense with or without range proposa=
l.</div></div></blockquote><div><br>Probably yes, although I'm afraid it wo=
uld still be inconvenient&nbsp;<span style=3D"font-size: 13.3333330154419px=
;">enough</span><span style=3D"font-size: 13px;">&nbsp;(due to the begin()/=
end() noise) for users to opt for a custom wrapper, which would defeat the =
purpose.&nbsp;</span></div><div>&nbsp;<br>Kind regards,<br><br>Andy</div></=
div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1505_1151338503.1420296934317--
------=_Part_1504_1088568128.1420296934316--

.

------=_Part_103_1948779410.1420297413537
Content-Type: multipart/alternative;
 boundary="----=_Part_104_1862443473.1420297413537"

------=_Part_104_1862443473.1420297413537
Content-Type: text/plain; charset=UTF-8

On Saturday, January 3, 2015 3:55:34 PM UTC+1, Andy Prowl wrote:
>
> On Saturday, January 3, 2015 3:38:25 PM UTC+1, Olaf van der Spek wrote:
>>
>> I think the last point (Point 3) from the beginning of this message calls
>> for some deeper consideration: an std::contains() algorithm taking a
>> container and an element would only make sense in the context of the Range
>> proposal, because current algorithms all take pairs of iterators.
>>
>
>> IMO a variant taking a range makes sense with or without range proposal.
>>
>
> Probably yes, although I'm afraid it would still be inconvenient enough (due
> to the begin()/end() noise) for users to opt for a custom wrapper, which
> would defeat the purpose.
>

Oops, sorry, I think I misread here and thought you were talking about the
overload taking a pair of iterators.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_104_1862443473.1420297413537
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, January 3, 2015 3:55:34 PM UTC+1, Andy Prowl =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Satu=
rday, January 3, 2015 3:38:25 PM UTC+1, Olaf van der Spek wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"font-size: 13p=
x;">I think the last point (Point 3) from the beginning of this message cal=
ls for some deeper consideration: an std::contains() algorithm taking a con=
tainer and an element would only make sense in the context of the Range pro=
posal, because current algorithms all take pairs of iterators.</span><br></=
div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div><br></div><div>IMO a variant taking a range makes sense with or without=
 range proposal.</div></div></blockquote><div><br>Probably yes, although I'=
m afraid it would still be inconvenient&nbsp;<span style=3D"font-size:13.33=
33330154419px">enough</span><span style=3D"font-size:13px">&nbsp;(due to th=
e begin()/end() noise) for users to opt for a custom wrapper, which would d=
efeat the purpose.&nbsp;</span></div></div></blockquote><div><br></div><div=
>Oops, sorry, I think I misread here and thought you were talking about the=
 overload taking a pair of iterators.<br><br>Kind regards,<br><br>Andy&nbsp=
;</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_104_1862443473.1420297413537--
------=_Part_103_1948779410.1420297413537--

.

------=_Part_2629_956838688.1420461155132
Content-Type: multipart/alternative;
 boundary="----=_Part_2630_1230280480.1420461155132"

------=_Part_2630_1230280480.1420461155132
Content-Type: text/plain; charset=UTF-8



On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
>
> Correct me if I'm wrong, but I see contains() as a not-so-big of an
> addition to the standard library that would be of quite significant value.
>
>
Leo, will you write an official proposal?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2630_1230280480.1420461155132
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, December 25, 2014 7:40:40 AM UTC+1, L=
eo Heinsaar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><span style=3D"font-size:13px">Correct me if I'm wrong, but I see=
 contains() as a not-so-big of an addition to the standard library that wou=
ld be of quite significant value.</span></div><div><br></div></div></blockq=
uote><div><br></div><div>Leo, will you write an official proposal?&nbsp;</d=
iv></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2630_1230280480.1420461155132--
------=_Part_2629_956838688.1420461155132--

.

------=_Part_4022_830435033.1420476339003
Content-Type: multipart/alternative;
 boundary="----=_Part_4023_939346428.1420476339011"

------=_Part_4023_939346428.1420476339011
Content-Type: text/plain; charset=UTF-8


>
> On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
>>
>> Correct me if I'm wrong, but I see contains() as a not-so-big of an
>> addition to the standard library that would be of quite significant value.
>>
>>
> Leo, will you write an official proposal?
>

I have a couple of questions and concerns.

1) Because the upcoming ranges and concepts will significantly affect STL
algorithms and containers, wouldn't it be a better idea to wait until those
two crystallize before promoting contains() in an official proposal?


Also, since I'm rather new to this group and the process:

2) Based on the overall discussion about contains() so far, would folks say
there is enough consensus about it for an official proposal (whenever it
makes more sense to write one)?


Leo

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4023_939346428.1420476339011
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"f=
ont-size:13px">Correct me if I'm wrong, but I see contains() as a not-so-bi=
g of an addition to the standard library that would be of quite significant=
 value.</span></div><div><br></div></div></blockquote><div><br></div><div>L=
eo, will you write an official proposal?&nbsp;</div></div></blockquote><div=
><br></div><div>I have a couple of questions and concerns.</div><div><br></=
div><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><=
div>1) Because the upcoming ranges and concepts will significantly affect S=
TL algorithms and containers, wouldn't it be a better idea to wait until th=
ose two crystallize before promoting contains() in an official proposal?</d=
iv></blockquote><div><br></div><div>Also, since I'm rather new to this grou=
p and the process:</div><div><br></div><blockquote style=3D"margin: 0 0 0 4=
0px; border: none; padding: 0px;"><div>2) Based on the overall discussion a=
bout contains() so far, would folks say there is enough consensus about it =
for an official proposal (whenever it makes more sense to write one)?</div>=
</blockquote><div><br></div><div>Leo</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4023_939346428.1420476339011--
------=_Part_4022_830435033.1420476339003--

.

------=_Part_13146_1447529370.1420559713599
Content-Type: multipart/alternative;
 boundary="----=_Part_13147_1931368374.1420559713599"

------=_Part_13147_1931368374.1420559713599
Content-Type: text/plain; charset=UTF-8

On Monday, January 5, 2015 5:45:39 PM UTC+1, Leo Heinsaar wrote:
>
> On Thursday, December 25, 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:
>>>
>>> Correct me if I'm wrong, but I see contains() as a not-so-big of an
>>> addition to the standard library that would be of quite significant value.
>>>
>>>
>> Leo, will you write an official proposal?
>>
>
> I have a couple of questions and concerns.
>
> 1) Because the upcoming ranges and concepts will significantly affect STL
> algorithms and containers, wouldn't it be a better idea to wait until those
> two crystallize before promoting contains() in an official proposal?
>
>
I think it may make sense to bring this issue (and perhaps this thread) to
Eric Niebler's attention. He will be able to contextualize the problem
within his work on Ranges - which he knows best than anyone else - and
provide guidance or suggestions on how to tackle it and/or write a formal
proposal.


> Also, since I'm rather new to this group and the process:
>
> 2) Based on the overall discussion about contains() so far, would folks
> say there is enough consensus about it for an official proposal (whenever
> it makes more sense to write one)?
>
>
I don't think we can say there is consensus, but I think we can say there
are good reasons why many people would want this functionality, and this
may eventually result in consensus on a larger scale (and/or at a higher
level). I would not take the lack of consensus *here *as a showstopper for
this feature.

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_13147_1931368374.1420559713599
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, January 5, 2015 5:45:39 PM UTC+1, Leo Heinsaar =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, December 25,=
 2014 7:40:40 AM UTC+1, Leo Heinsaar wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:13px">Correct me if =
I'm wrong, but I see contains() as a not-so-big of an addition to the stand=
ard library that would be of quite significant value.</span></div><div><br>=
</div></div></blockquote><div><br></div><div>Leo, will you write an officia=
l proposal?&nbsp;</div></div></blockquote><div><br></div><div>I have a coup=
le of questions and concerns.</div><div><br></div><blockquote style=3D"marg=
in:0 0 0 40px;border:none;padding:0px"><div>1) Because the upcoming ranges =
and concepts will significantly affect STL algorithms and containers, would=
n't it be a better idea to wait until those two crystallize before promotin=
g contains() in an official proposal?</div></blockquote></div></blockquote>=
<div><br>I think it may make sense to bring this issue (and perhaps this th=
read) to Eric Niebler's attention. He will be able to contextualize the pro=
blem within his work on Ranges - which he knows best than anyone else - and=
 provide guidance or suggestions on how to tackle it and/or write a formal =
proposal.&nbsp;<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div></div><div>Also, since I'm rather new to this group =
and the process:</div><div><br></div><blockquote style=3D"margin:0 0 0 40px=
;border:none;padding:0px"><div>2) Based on the overall discussion about con=
tains() so far, would folks say there is enough consensus about it for an o=
fficial proposal (whenever it makes more sense to write one)?</div></blockq=
uote></div></blockquote><div><br></div>I don't think we can say there is co=
nsensus, but I think we can say there are good reasons why many people woul=
d want this functionality, and this may eventually result in consensus on a=
 larger scale (and/or at a higher level). I would not take the lack of cons=
ensus <i>here </i>as a&nbsp;showstopper for this feature.<div><br>Kind rega=
rds,<br><br>Andy</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_13147_1931368374.1420559713599--
------=_Part_13146_1447529370.1420559713599--

.

------=_Part_2198_130477879.1420564416000
Content-Type: multipart/alternative;
 boundary="----=_Part_2199_360908766.1420564416000"

------=_Part_2199_360908766.1420564416000
Content-Type: text/plain; charset=UTF-8


>
> 1) Because the upcoming ranges and concepts will significantly affect STL
>> algorithms and containers, wouldn't it be a better idea to wait until those
>> two crystallize before promoting contains() in an official proposal?
>>
>>
> I think it may make sense to bring this issue (and perhaps this thread) to
> Eric Niebler's attention. He will be able to contextualize the problem
> within his work on Ranges - which he knows best than anyone else - and
> provide guidance or suggestions on how to tackle it and/or write a formal
> proposal.
>

I was just reading through the *discussion on ranges by Eric, Sean and
Andrew* <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html>.
All right, I'll write to Eric about this in the coming days.


>  Also, since I'm rather new to this group and the process:
>

>> 2) Based on the overall discussion about contains() so far, would folks
>> say there is enough consensus about it for an official proposal (whenever
>> it makes more sense to write one)?
>>
>>
> I don't think we can say there is consensus, but I think we can say there
> are good reasons why many people would want this functionality, and this
> may eventually result in consensus on a larger scale (and/or at a higher
> level). I would not take the lack of consensus *here *as a showstopper
> for this feature.
>

Okay, that's what I essentially wanted to know - thanks Andy.

Leo

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2199_360908766.1420564416000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote st=
yle=3D"margin:0 0 0 40px;border:none;padding:0px">1) Because the upcoming r=
anges and concepts will significantly affect STL algorithms and containers,=
 wouldn't it be a better idea to wait until those two crystallize before pr=
omoting contains() in an official proposal?</blockquote></div></blockquote>=
<div><br>I think it may make sense to bring this issue (and perhaps this th=
read) to Eric Niebler's attention. He will be able to contextualize the pro=
blem within his work on Ranges - which he knows best than anyone else - and=
 provide guidance or suggestions on how to tackle it and/or write a formal =
proposal.&nbsp;</div></div></blockquote><div><br></div><div>I was just read=
ing through the<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2014/n4128.html"> <u>discussion on ranges by Eric, Sean and Andrew</u></a=
>. All right, I'll write to Eric about this in the coming days.</div><div>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>&nbsp;Also, since I'm rather new to this group and the process:&nbsp;</d=
iv></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>=
2) Based on the overall discussion about contains() so far, would folks say=
 there is enough consensus about it for an official proposal (whenever it m=
akes more sense to write one)?</div></blockquote></div></blockquote><div><b=
r></div>I don't think we can say there is consensus, but I think we can say=
 there are good reasons why many people would want this functionality, and =
this may eventually result in consensus on a larger scale (and/or at a high=
er level). I would not take the lack of consensus <i>here </i>as a&nbsp;sho=
wstopper for this feature.</div></blockquote><div><br></div><div>Okay, that=
's what I essentially wanted to know - thanks Andy.&nbsp;</div><div>&nbsp;<=
/div><div>Leo</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2199_360908766.1420564416000--
------=_Part_2198_130477879.1420564416000--

.