------=_Part_164_1194071197.1537396090291
Content-Type: multipart/alternative;
 boundary="----=_Part_165_1530725474.1537396090291"

------=_Part_165_1530725474.1537396090291
Content-Type: text/plain; charset="UTF-8"

In C++14 the ability to find keys in maps without converting the provided
key to the key type of the map. Unfortunately this behaviour is not enabled
unless you provide your own Compare, which you have to make yourself. There
is obviously some reason to require the is_transparent typedef to exist in
the Compare class, although it doesn't seem likely to me. Well, if the
constructor we are avoiding has side effects it would count as a changed
behaviour but is this reason enough, it is after all sort of violating the
contract of a constructor, and we did allow ourself to change the copy
elision rules for return values...

Anyhow, I think some improvements can be made. Here are a few suggestions
in order of more risk/benefit to less:

1. Add the is_transparent typedef to std::less and make its operator() a
template. This mostly undoes the effect of having is_transparent keying in
the first place, so it will probably be considered too risky by some.

2. Specialize std::less for std::string at least, as string to T maps are
very common, and I think most users would think that this functionality is
"working in regular std::map<std::string, T> objects already. It's not!
This should be safe as there should be no visible effects of not having to
construct an extra string before doing the operator<.

3. Add a std::transparent_less  template which can be used in maps more
easily than having to create your own Compare every time.

For reasons of symmetry I assume this change on any of the levels would be
implemented in parallel for all the other templates: greater, greater_equal
etc.


Another issue is that operator[] does not do the polymorphic compare even
if is_transparent is present. I don't really understand this difference as
we currently need the Key type to be constructible from whatever type is
provided as the key argument to the operator, the only difference would be
that we don't invoke this constructor unless we really have to add an
element to the map (at which time we obviously must construct a key value
to store). If we access the same element many times (which is common for
read accesses) there are many copies to save.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/419ec67b-93fc-4b3f-9119-b6a071ccff7c%40isocpp.org.

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

<div dir=3D"ltr">In C++14 the ability to find keys in maps without converti=
ng the provided key to the key type of the map. Unfortunately this behaviou=
r is not enabled unless you provide your own Compare, which you have to mak=
e yourself. There is obviously some reason to require the is_transparent ty=
pedef to exist in the Compare class, although it doesn&#39;t seem likely to=
 me. Well, if the constructor we are avoiding has side effects it would cou=
nt as a changed behaviour but is this reason enough, it is after all sort o=
f violating the contract of a constructor, and we did allow ourself to chan=
ge the copy elision rules for return values...<div><br></div><div>Anyhow, I=
 think some improvements can be made. Here are a few suggestions in order o=
f more risk/benefit to less:</div><div><br></div><div>1. Add the is_transpa=
rent typedef to std::less and make its operator() a template. This mostly u=
ndoes the effect of having is_transparent keying in the first place, so it =
will probably be considered too risky by some.</div><div><br></div><div>2. =
Specialize std::less for std::string at least, as string to T maps are very=
 common, and I think most users would think that this functionality is &quo=
t;working in regular std::map&lt;std::string, T&gt; objects already. It&#39=
;s not! This should be safe as there should be no visible effects of not ha=
ving to construct an extra string before doing the operator&lt;.</div><div>=
<br></div><div>3. Add a std::transparent_less=C2=A0 template which can be u=
sed in maps more easily than having to create your own Compare every time.<=
br><div><br></div><div>For reasons of symmetry I assume this change on any =
of the levels would be implemented in parallel for all the other templates:=
 greater, greater_equal etc.</div><div><br></div></div><div><br></div><div>=
Another issue is that operator[] does not do the polymorphic compare even i=
f is_transparent is present. I don&#39;t really understand this difference =
as we currently need the Key type to be constructible from whatever type is=
 provided as the key argument to the operator, the only difference would be=
 that we don&#39;t invoke this constructor unless we really have to add an =
element to the map (at which time we obviously must construct a key value t=
o store). If we access the same element many times (which is common for rea=
d accesses) there are many copies to save.</div><div><br></div></div>

<p></p>

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

------=_Part_165_1530725474.1537396090291--

------=_Part_164_1194071197.1537396090291--

.

------=_Part_177_1309674151.1537404879628
Content-Type: multipart/alternative;
 boundary="----=_Part_178_627032019.1537404879628"

------=_Part_178_627032019.1537404879628
Content-Type: text/plain; charset="UTF-8"

On Thursday, 20 September 2018 10:28:10 UTC+12, Bengt Gustafsson wrote:
>
> 1. Add the is_transparent typedef to std::less and make its operator() a
> template. This mostly undoes the effect of having is_transparent keying in
> the first place, so it will probably be considered too risky by some.
>

This is exactly what the existing (C++14) std::less<void> specialization
does.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01273684-f057-405e-a168-417244c4f490%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, 20 September 2018 10:28:10 UTC+12, Bengt Gust=
afsson  wrote:<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"=
><div>1. Add the is_transparent typedef to std::less and make its operator(=
) a template. This mostly undoes the effect of having is_transparent keying=
 in the first place, so it will probably be considered too risky by some.</=
div></div></blockquote><div><br></div><div><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(102, 0, 102);">This</span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span class=3D"styled-=
by-prettify" style=3D"color: rgb(0, 0, 136);">is</span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(0, 0, 0);">=C2=A0exactly what the existi=
ng (C++14)=C2=A0<font face=3D"courier new, monospace">std</font></span><fon=
t face=3D"courier new, monospace"><span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 102, 0);">::</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 0);">less</span><span class=3D"styled-by-prettify"=
 style=3D"color: rgb(0, 136, 0);">&lt;void&gt;</span></font><span class=3D"=
styled-by-prettify" style=3D"color: rgb(0, 0, 0);">=C2=A0specialization doe=
s</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0)=
;">.</span></div></div>

<p></p>

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

------=_Part_178_627032019.1537404879628--

------=_Part_177_1309674151.1537404879628--

.

------=_Part_290_221112139.1537429012175
Content-Type: multipart/alternative;
 boundary="----=_Part_291_613158611.1537429012176"

------=_Part_291_613158611.1537429012176
Content-Type: text/plain; charset="UTF-8"



>
> This is exactly what the existing (C++14) std::less<void> specialization
> does.
>

Thanks for the information. It is really hard to keep up with all these
small changes in the library. So now you should declare your maps:

std::map<std::string, MyType, std::less<>> myMap;

Fair enough, if just making it "work" was considered too risky.

It still bothers me that this does not include operator[], and I don't see
why.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9094cc47-cb95-4dd7-8de5-594ae5a84fdb%40isocpp.org.

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

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br></div><div><span style=3D"color:rgb(102,0,102)">This</spa=
n><span style=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"color:rgb(0,=
0,136)">is</span><span style=3D"color:rgb(0,0,0)">=C2=A0exactly what the ex=
isting (C++14)=C2=A0<font face=3D"courier new, monospace">std</font></span>=
<font face=3D"courier new, monospace"><span style=3D"color:rgb(102,102,0)">=
::</span><span style=3D"color:rgb(0,0,0)">less</span><span style=3D"color:r=
gb(0,136,0)">&lt;void&gt;</span></font><span style=3D"color:rgb(0,0,0)">=C2=
=A0<wbr>specialization does</span><span style=3D"color:rgb(102,102,0)">.</s=
pan></div></div></blockquote><div><br></div><div>Thanks for the information=
.. It is really hard to keep up with all these small changes in the library.=
 So now you should declare your maps:</div><div><br></div><div>std::map&lt;=
std::string, MyType, std::less&lt;&gt;&gt; myMap;</div><div><br></div><div>=
Fair enough, if just making it &quot;work&quot; was considered too risky.</=
div><div><br></div><div>It still bothers me that this does not include oper=
ator[], and I don&#39;t see why.=C2=A0</div></div>

<p></p>

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

------=_Part_291_613158611.1537429012176--

------=_Part_290_221112139.1537429012175--

.