------=_Part_6736_310402909.1499708849349
Content-Type: multipart/alternative;
 boundary="----=_Part_6737_319643926.1499708849350"

------=_Part_6737_319643926.1499708849350
Content-Type: text/plain; charset="UTF-8"

Hi,

I propose to add to <iterator>:

1) std::mbegin(container)/std::mend
Semantics: Return moveable iterators, exactly the same as
std::make_move_iterator(std::begin(container))
Why: We already have std::begin and std::cbegin and I believe this is a odd
one out for consistency

2) std::make_const_iterator(iterator)
Semantics: return iterator static_cast-ed to const_iterator
Why: We have std::make_move_iterator so again I believe this is missing.
Container requirements (23.2) specify that iterators must be convertible to
const_iterator so I believe this is just a static_cast.

3) std::container_of_t<decltype(iterator)>
Semantics: determine the container type of the iterator
Why: Helpful to implement 2 above, also helpful in a variety of situations
where there's a need to check requirements on the container of an iterator.

Thanks,
-- Giovanni

--
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/e45d0f40-ac12-4df3-9532-8c9481e7791a%40isocpp.org.

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

<div dir=3D"ltr">Hi,<div><br></div><div>I propose to add to &lt;iterator&gt=
;:</div><div><br></div><div>1) std::mbegin(container)/std::mend</div><div>S=
emantics: Return moveable iterators, exactly the same as std::make_move_ite=
rator(std::begin(container))</div><div>Why: We already have std::begin and =
std::cbegin and I believe this is a odd one out for consistency</div><div><=
br></div><div>2) std::make_const_iterator(iterator)</div><div>Semantics: re=
turn iterator static_cast-ed to const_iterator</div><div>Why: We have std::=
make_move_iterator so again I believe this is missing. Container requiremen=
ts (23.2) specify that iterators must be convertible to const_iterator so I=
 believe this is just a static_cast.</div><div><br></div><div>3) std::conta=
iner_of_t&lt;decltype(iterator)&gt;</div><div>Semantics: determine the cont=
ainer type of the iterator</div><div>Why: Helpful to implement 2 above, als=
o helpful in a variety of situations where there&#39;s a need to check requ=
irements on the container of an iterator.</div><div><br></div><div>Thanks,<=
/div><div>-- Giovanni</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/e45d0f40-ac12-4df3-9532-8c9481e7791a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e45d0f40-ac12-4df3-9532-8c9481e7791a=
%40isocpp.org</a>.<br />

------=_Part_6737_319643926.1499708849350--

------=_Part_6736_310402909.1499708849349--

.

2017-07-10 19:47 GMT+02:00  <gafunchal@gmail.com>:
> Hi,
>
> I propose to add to <iterator>:

[..]

> 2) std::make_const_iterator(iterator)
> Semantics: return iterator static_cast-ed to const_iterator
> Why: We have std::make_move_iterator so again I believe this is missing.
> Container requirements (23.2) specify that iterators must be convertible to
> const_iterator so I believe this is just a static_cast.
>
> 3) std::container_of_t<decltype(iterator)>
> Semantics: determine the container type of the iterator
> Why: Helpful to implement 2 above, also helpful in a variety of situations
> where there's a need to check requirements on the container of an iterator.

These two proposals make assumptions that are neither met by current
implementations nor implied by the standard: There is no 1:1 relation
between container type and iterator type, which makes both (2) and (3)
impossible. It would also break non-Standard-Library implementations
of containers such as from Boost or other third-party libraries.

- Daniel

--
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/CAGNvRgBnrZXiiQQy_8eVukE-F365uuXgwFMffvdNbyJ%2B_S%3DO2g%40mail.gmail.com.

.

------=_Part_1858_869514192.1499711724064
Content-Type: multipart/alternative;
 boundary="----=_Part_1859_1324128622.1499711724064"

------=_Part_1859_1324128622.1499711724064
Content-Type: text/plain; charset="UTF-8"

On Monday, July 10, 2017 at 1:47:29 PM UTC-4, gafu...@gmail.com wrote:
>
> 3) std::container_of_t<decltype(iterator)>
> Semantics: determine the container type of the iterator
> Why: Helpful to implement 2 above, also helpful in a variety of situations
> where there's a need to check requirements on the container of an iterator.
>

Someone with more knowledge of template metaprogramming and the type system
than I do needs to weigh in on this, but I'm not sure if this is currently
possible in ISO C++.

An alternative might be something like

std::container_from_value_type<ValueType, Container=std::vector<ValueType>>
std::container_from_iterator<Iterator,Container=std::vector<std::
remove_pointer_t<Iterator>>

-Ray

--
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/00dbc427-c520-42f8-b92d-6c12d600483f%40isocpp.org.

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

<div dir=3D"ltr">On Monday, July 10, 2017 at 1:47:29 PM UTC-4, gafu...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color:=
 rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div>3) std::cont=
ainer_of_t&lt;decltype(<wbr>iterator)&gt;</div><div>Semantics: determine th=
e container type of the iterator</div><div>Why: Helpful to implement 2 abov=
e, also helpful in a variety of situations where there&#39;s a need to chec=
k requirements on the container of an iterator.</div></div></blockquote><di=
v><br></div><div>Someone with more knowledge of template metaprogramming an=
d the type system than I do needs to weigh in on this, but I&#39;m not sure=
 if this is currently possible in ISO C++.</div><div><br></div><div>An alte=
rnative might be something like</div><div><br></div><div><div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border: 1px solid r=
gb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">container_from_value_type</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">ValueType</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Container</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">ValueType</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">container_from_iterator</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Iterator</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Container</span><span style=3D"color: #660;=
" class=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"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">vector</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">remove_pointer_t=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Iterator</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;</span></f=
ont></div></code></div></div><br><div>-Ray</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/00dbc427-c520-42f8-b92d-6c12d600483f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00dbc427-c520-42f8-b92d-6c12d600483f=
%40isocpp.org</a>.<br />

------=_Part_1859_1324128622.1499711724064--

------=_Part_1858_869514192.1499711724064--

.

------=_Part_1126_1952021706.1499712245246
Content-Type: multipart/alternative;
 boundary="----=_Part_1127_872854087.1499712245246"

------=_Part_1127_872854087.1499712245246
Content-Type: text/plain; charset="UTF-8"

On a second look that suggestion of mine doesn't make any sense, but you
could have vector_from_(value_type|iterator),
list_from_(value_type|iterator) and so on for the standard containers.

--
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/a60182de-3aff-4f03-81e6-d3d2aa665909%40isocpp.org.

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

<div dir=3D"ltr">On a second look that suggestion of mine doesn&#39;t make =
any sense, but you could have <font face=3D"courier new, monospace">vector_=
from_(value_type|iterator)</font><font face=3D"arial, sans-serif">, </font>=
<font face=3D"courier new, monospace">list_from_(value_type|iterator)</font=
><font face=3D"arial, sans-serif">=C2=A0and so on for the standard containe=
rs.</font></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/a60182de-3aff-4f03-81e6-d3d2aa665909%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a60182de-3aff-4f03-81e6-d3d2aa665909=
%40isocpp.org</a>.<br />

------=_Part_1127_872854087.1499712245246--

------=_Part_1126_1952021706.1499712245246--

.

--001a1141c70c76c2260553fb0a53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 10, 2017 at 11:21 AM, Daniel Kr=C3=BCgler <daniel.kruegler@gmai=
l.com>
wrote:

> 2017-07-10 19:47 GMT+02:00  <gafunchal@gmail.com>:
> > Hi,
> >
> > I propose to add to <iterator>:
>
> [..]
>
> > 2) std::make_const_iterator(iterator)
> > Semantics: return iterator static_cast-ed to const_iterator
> > Why: We have std::make_move_iterator so again I believe this is missing=
..
> > Container requirements (23.2) specify that iterators must be convertibl=
e
> to
> > const_iterator so I believe this is just a static_cast.
> >
> > 3) std::container_of_t<decltype(iterator)>
> > Semantics: determine the container type of the iterator
> > Why: Helpful to implement 2 above, also helpful in a variety of
> situations
> > where there's a need to check requirements on the container of an
> iterator.
>
> These two proposals make assumptions that are neither met by current
> implementations nor implied by the standard: There is no 1:1 relation
> between container type and iterator type, which makes both (2) and (3)
> impossible. It would also break non-Standard-Library implementations
> of containers such as from Boost or other third-party libraries.
>

I think 2 is possible though it may not necessarily have desirable
properties. It can have a generic implementation that returns a
std::const_iterator<Iterator> (where std::const_iterator is an adaptor
template similar to std::move_iterator). It can be partially specialized on
T* to return const T* and then container libraries can add custom overloads
for their own iterator types that will be found via ADL, but only if the
iterator type isn't T* or something like that.

--=20
*Brian Bi*

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

--001a1141c70c76c2260553fb0a53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jul 10, 2017 at 11:21 AM, Daniel Kr=C3=BCgler <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.=
kruegler@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">2017-07-10 19:47 GMT+02:00=C2=A0 &lt;<a href=3D"mailto:gaf=
unchal@gmail.com">gafunchal@gmail.com</a>&gt;:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I propose to add to &lt;iterator&gt;:<br>
<br>
</span>[..]<br>
<span class=3D""><br>
&gt; 2) std::make_const_iterator(<wbr>iterator)<br>
&gt; Semantics: return iterator static_cast-ed to const_iterator<br>
&gt; Why: We have std::make_move_iterator so again I believe this is missin=
g.<br>
&gt; Container requirements (23.2) specify that iterators must be convertib=
le to<br>
&gt; const_iterator so I believe this is just a static_cast.<br>
&gt;<br>
&gt; 3) std::container_of_t&lt;decltype(<wbr>iterator)&gt;<br>
&gt; Semantics: determine the container type of the iterator<br>
&gt; Why: Helpful to implement 2 above, also helpful in a variety of situat=
ions<br>
&gt; where there&#39;s a need to check requirements on the container of an =
iterator.<br>
<br>
</span>These two proposals make assumptions that are neither met by current=
<br>
implementations nor implied by the standard: There is no 1:1 relation<br>
between container type and iterator type, which makes both (2) and (3)<br>
impossible. It would also break non-Standard-Library implementations<br>
of containers such as from Boost or other third-party libraries.<br></block=
quote><div><br></div><div>I think 2 is possible though it may not necessari=
ly have desirable properties. It can have a generic implementation that ret=
urns a std::const_iterator&lt;Iterator&gt; (where std::const_iterator is an=
 adaptor template similar to std::move_iterator). It can be partially speci=
alized on T* to return const T* and then container libraries can add custom=
 overloads for their own iterator types that will be found via ADL, but onl=
y if the iterator type isn&#39;t T* or something like that.<br></div><div>=
=C2=A0</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"g=
mail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0=
c0"><i>Brian Bi</i></font><br><div></div><div></div><div></div></div></div>=
</div></div>
</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/CAMmfjbPSGa_AiSOieY9jo9FPY5EaZn852RGT=
MO85kV%2Bh7CRMig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPSGa_AiS=
OieY9jo9FPY5EaZn852RGTMO85kV%2Bh7CRMig%40mail.gmail.com</a>.<br />

--001a1141c70c76c2260553fb0a53--

.

--94eb2c12542a6c5121055403e038
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 10, 2017 at 7:49 PM, Brian Bi <bbi5291@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 11:21 AM, Daniel Kr=C3=BCgler <
> daniel.kruegler@gmail.com> wrote:
>
>> 2017-07-10 19:47 GMT+02:00  <gafunchal@gmail.com>:
>> > Hi,
>> >
>> > I propose to add to <iterator>:
>>
>> [..]
>>
>> > 2) std::make_const_iterator(iterator)
>> > Semantics: return iterator static_cast-ed to const_iterator
>> > Why: We have std::make_move_iterator so again I believe this is missin=
g.
>> > Container requirements (23.2) specify that iterators must be
>> convertible to
>> > const_iterator so I believe this is just a static_cast.
>> >
>> > 3) std::container_of_t<decltype(iterator)>
>> > Semantics: determine the container type of the iterator
>> > Why: Helpful to implement 2 above, also helpful in a variety of
>> situations
>> > where there's a need to check requirements on the container of an
>> iterator.
>>
>> These two proposals make assumptions that are neither met by current
>> implementations nor implied by the standard: There is no 1:1 relation
>> between container type and iterator type, which makes both (2) and (3)
>> impossible. It would also break non-Standard-Library implementations
>> of containers such as from Boost or other third-party libraries.
>
>
I agree with Daniel's point that the 1:1 relation between container and
iterator types is not currently mandated. However:
- I believe it only affects (3).
- Due to std::iterator_traits<iterator>, iterators know something about
their container (iterator_category) so there is already limited scope for
an iterator to be used in multiple containers. BTW, perhaps
std::iterator_traits<iterator>::iterator_container would be a better place
for (3).
- I'm not sure I understand your claim that existing code would break. I
envision it as a template specialized to std container's iterators and
other container libraries could add their own specializations similarly to
what is already done for example in std::hash.


> I think 2 is possible though it may not necessarily have desirable
> properties. It can have a generic implementation that returns a
> std::const_iterator<Iterator> (where std::const_iterator is an adaptor
> template similar to std::move_iterator). It can be partially specialized =
on
> T* to return const T* and then container libraries can add custom overloa=
ds
> for their own iterator types that will be found via ADL, but only if the
> iterator type isn't T* or something like that.
>

I like Brian's idea of std::const_iterator as an adaptor template.

Thanks,
-- Giovanni

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKDaRuKMi7w3umi3JZ%3D44Vypc3C_%2BCFiVpE9dHC4Ys-=
uf0UDFg%40mail.gmail.com.

--94eb2c12542a6c5121055403e038
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_signature">=
On Mon, Jul 10, 2017 at 7:49 PM, Brian Bi <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bbi5291@gmail.com" target=3D"_blank">bbi5291@gmail.com</a>&gt;</span=
> wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D"gmail-">On Mon, Jul 10, 2017 at 11:21 AM, D=
aniel Kr=C3=BCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@=
gmail.com" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><span>2017-07-10 19:=
47 GMT+02:00=C2=A0 &lt;<a href=3D"mailto:gafunchal@gmail.com" target=3D"_bl=
ank">gafunchal@gmail.com</a>&gt;:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I propose to add to &lt;iterator&gt;:<br>
<br>
</span>[..]<br>
<span><br>
&gt; 2) std::make_const_iterator(itera<wbr>tor)<br>
&gt; Semantics: return iterator static_cast-ed to const_iterator<br>
&gt; Why: We have std::make_move_iterator so again I believe this is missin=
g.<br>
&gt; Container requirements (23.2) specify that iterators must be convertib=
le to<br>
&gt; const_iterator so I believe this is just a static_cast.<br>
&gt;<br>
&gt; 3) std::container_of_t&lt;decltype(i<wbr>terator)&gt;<br>
&gt; Semantics: determine the container type of the iterator<br>
&gt; Why: Helpful to implement 2 above, also helpful in a variety of situat=
ions<br>
&gt; where there&#39;s a need to check requirements on the container of an =
iterator.<br>
<br>
</span>These two proposals make assumptions that are neither met by current=
<br>
implementations nor implied by the standard: There is no 1:1 relation<br>
between container type and iterator type, which makes both (2) and (3)<br>
impossible. It would also break non-Standard-Library implementations<br>
of containers such as from Boost or other third-party libraries.</blockquot=
e></span></div></div></div></blockquote><div><div><br></div><div>I agree wi=
th Daniel&#39;s point that the 1:1 relation between container and iterator =
types is not currently mandated. However:</div><div>- I believe it only aff=
ects (3).</div><div>- Due to std::iterator_traits&lt;iterator&gt;, iterator=
s know something about their container (iterator_category) so there is alre=
ady limited scope for an iterator to be used in multiple containers. BTW, p=
erhaps std::iterator_traits&lt;iterator&gt;::iterator_container would be a =
better place for (3).<br></div><div>- I&#39;m not sure I understand your cl=
aim that existing code would break. I envision it as a template specialized=
 to std container&#39;s iterators and other container libraries could add t=
heir own specializations similarly to what is already done for example in s=
td::hash.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><span class=3D"gmail-"><div></div></span><div>I think 2 is possibl=
e though it may not necessarily have desirable properties. It can have a ge=
neric implementation that returns a std::const_iterator&lt;Iterator&gt; (wh=
ere std::const_iterator is an adaptor template similar to std::move_iterato=
r). It can be partially specialized on T* to return const T* and then conta=
iner libraries can add custom overloads for their own iterator types that w=
ill be found via ADL, but only if the iterator type isn&#39;t T* or somethi=
ng like that.<br></div><div></div></div></div></div></blockquote><div><br><=
/div><div>I like Brian&#39;s idea of std::const_iterator as an adaptor temp=
late.</div><div><br></div><div>Thanks,</div><div>-- Giovanni<br></div></div=
></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/CAKDaRuKMi7w3umi3JZ%3D44Vypc3C_%2BCFi=
VpE9dHC4Ys-uf0UDFg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKDaRuKMi7w3=
umi3JZ%3D44Vypc3C_%2BCFiVpE9dHC4Ys-uf0UDFg%40mail.gmail.com</a>.<br />

--94eb2c12542a6c5121055403e038--

.

On segunda-feira, 10 de julho de 2017 22:21:10 PDT Giovanni Funchal wrote:
> I agree with Daniel's point that the 1:1 relation between container and
> iterator types is not currently mandated. However:
> - I believe it only affects (3).

Strictly speaking, yes. But (2) is also difficult to achieve. You're asking for
a way to transform an iterator to const_iterator, but those types are often
unrelated. For example, for libstdc++'s std::unordered_map, the two iterator
classes are just aliases to std::__detail::_Node_const_iterator and
std::__detail::_Node_iterator.

A const iterator is not the same as a const_iterator.

> - Due to std::iterator_traits<iterator>, iterators know something about
> their container (iterator_category) so there is already limited scope for
> an iterator to be used in multiple containers. BTW, perhaps
> std::iterator_traits<iterator>::iterator_container would be a better place
> for (3).

First, the category is the category of the iterator, not of the container.
Second, you cannot have a link back to the container, period. (3) is simply
unachievable. Just think of this, what should this be

 std::iterator_traits<char *>::container

choose:
 std::vector<char>
 std::string
  std::basic_string<char, any trait, any allocator> really...
 std::array<char, N>
 QVector<char>
 QByteArray

> - I'm not sure I understand your claim that existing code would break. I
> envision it as a template specialized to std container's iterators and
> other container libraries could add their own specializations similarly to
> what is already done for example in std::hash.

Right, if you're adding a new set of functions and new members in the
template, existing generic code that isn't using those functions or those
members cannot break.

The problem is when people start using them, but their generic code works with
only a few containers that have been updated. When someone else tries to use
it with some non-updated container, it breaks.

There needs to be a good reason to do what you're asking.

> > I think 2 is possible though it may not necessarily have desirable
> > properties. It can have a generic implementation that returns a
> > std::const_iterator<Iterator> (where std::const_iterator is an adaptor
> > template similar to std::move_iterator). It can be partially specialized
> > on
> > T* to return const T* and then container libraries can add custom
> > overloads
> > for their own iterator types that will be found via ADL, but only if the
> > iterator type isn't T* or something like that.
>
> I like Brian's idea of std::const_iterator as an adaptor template.

std::const_itererator<iterator> is not std::const_iterator. That means that if
you tried to use this in generic code that actually used the container's
const_iterator, it would fail.

Just try:

void f(std::unordered_map<int, int>::const_iterator);
void g(std::unordered_map<int, int>::iterator it)
{
 f(std::make_const_iterator(it));
}

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/9434787.nHRs7m2U1a%40tjmaciei-mobl1.

.

------=_Part_7290_1864966793.1499783765653
Content-Type: multipart/alternative;
 boundary="----=_Part_7291_1964673315.1499783765653"

------=_Part_7291_1964673315.1499783765653
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 11, 2017 at 2:14:08 AM UTC-4, Thiago Macieira wrote:
>
> On segunda-feira, 10 de julho de 2017 22:21:10 PDT Giovanni Funchal wrote:
> > I agree with Daniel's point that the 1:1 relation between container and
> > iterator types is not currently mandated. However:
> > - I believe it only affects (3).
>
> Strictly speaking, yes. But (2) is also difficult to achieve. You're
> asking for
> a way to transform an iterator to const_iterator, but those types are
> often
> unrelated. For example, for libstdc++'s std::unordered_map, the two
> iterator
> classes are just aliases to std::__detail::_Node_const_iterator and
> std::__detail::_Node_iterator.
>
> A const iterator is not the same as a const_iterator.
>
> > - Due to std::iterator_traits<iterator>, iterators know something about
> > their container (iterator_category) so there is already limited scope
> for
> > an iterator to be used in multiple containers. BTW, perhaps
> > std::iterator_traits<iterator>::iterator_container would be a better
> place
> > for (3).
>
> First, the category is the category of the iterator, not of the container.
> Second, you cannot have a link back to the container, period. (3) is
> simply
> unachievable. Just think of this, what should this be
>
>         std::iterator_traits<char *>::container
>
> choose:
>         std::vector<char>
>         std::string
>                 std::basic_string<char, any trait, any allocator>
> really...
>         std::array<char, N>
>         QVector<char>
>         QByteArray
>

Even better, what about iterators that do not have containers? Things like
iterator wrappers and mutators.

No algorithm has any right to query anything about the iterator's
container. That's the whole point of iterators: to be the intermediary
between the container of the data and the algorithm that acts on the data.
If there is something lacking in our iterator interfaces which algorithms
genuinely need, then *that* is what needs to be fixed.

--
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/6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, July 11, 2017 at 2:14:08 AM UTC-4, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, 1=
0 de julho de 2017 22:21:10 PDT Giovanni Funchal wrote:
<br>&gt; I agree with Daniel&#39;s point that the 1:1 relation between cont=
ainer and
<br>&gt; iterator types is not currently mandated. However:
<br>&gt; - I believe it only affects (3).
<br>
<br>Strictly speaking, yes. But (2) is also difficult to achieve. You&#39;r=
e asking for=20
<br>a way to transform an iterator to const_iterator, but those types are o=
ften=20
<br>unrelated. For example, for libstdc++&#39;s std::unordered_map, the two=
 iterator=20
<br>classes are just aliases to std::__detail::_Node_const_<wbr>iterator an=
d=20
<br>std::__detail::_Node_iterator.
<br>
<br>A const iterator is not the same as a const_iterator.
<br>
<br>&gt; - Due to std::iterator_traits&lt;iterator&gt;<wbr>, iterators know=
 something about
<br>&gt; their container (iterator_category) so there is already limited sc=
ope for
<br>&gt; an iterator to be used in multiple containers. BTW, perhaps
<br>&gt; std::iterator_traits&lt;iterator&gt;<wbr>::iterator_container woul=
d be a better place
<br>&gt; for (3).
<br>
<br>First, the category is the category of the iterator, not of the contain=
er.=20
<br>Second, you cannot have a link back to the container, period. (3) is si=
mply=20
<br>unachievable. Just think of this, what should this be
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::iterator_traits&lt=
;<wbr>char *&gt;::container
<br>
<br>choose:
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::vector&lt;char&gt;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::string
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0std::basic_<wbr>string&lt;char, any trait, any a=
llocator&gt; really...
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::array&lt;char, N&g=
t;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QVector&lt;char&gt;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QByteArray
<br></blockquote><div><br>Even better, what about iterators that do not hav=
e containers? Things like iterator wrappers and mutators.<br><br>No algorit=
hm has any right to query anything about the iterator&#39;s container. That=
&#39;s the whole point of iterators: to be the intermediary between the con=
tainer of the data and the algorithm that acts on the data. If there is som=
ething lacking in our iterator interfaces which algorithms genuinely need, =
then <i>that</i> is what needs to be fixed.</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/6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3=
%40isocpp.org</a>.<br />

------=_Part_7291_1964673315.1499783765653--

------=_Part_7290_1864966793.1499783765653--

.

--94eb2c12542a25a35205541048b0
Content-Type: text/plain; charset="UTF-8"

Hi,

Thanks Thiago, Nicol, those are some very good points and I now think like
you that (3) was a bad idea, but I still think proposals (1) and (2) might
make sense to propose as additions.

> Just try:

This works:

void f(std::unordered_map<int, int>::const_iterator) {}
void g(std::unordered_map<int, int>::iterator it)
{
    f(static_cast<std::unordered_map<int, int>::const_iterator>(it));
}

(this conversion is a container requirement)

Granted it is not trivial to implement std::make_const_iterator so that it
deduces the type to cast to, but I think disregarding implementation for
one second that this just points out how useful this feature would be if
g() needed a const_iterator for whatever reason, exactly because a
const_iterator is not a const iterator.

Furthermore, one way I like to reason about this is making the table below
which illustrates the asymmetry in available functionality:

(1) Iterator type -> access function templates
iterator (std::begin/std::end)
reverse_iterator (std::rbegin/std::rend)
const_iterator (std::cbegin/std::cend)
move_iterator (Missing std::mbegin/std::mend)

(2) Iterator type -> conversion function template
reverse_iterator (std::make_reverse_iterator)
const_iterator (Missing std::make_const_iterator)
move_iterator (std::make_move_iterator)

Thanks,
-- Giovanni



On Tue, Jul 11, 2017 at 3:36 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, July 11, 2017 at 2:14:08 AM UTC-4, Thiago Macieira wrote:
>>
>> On segunda-feira, 10 de julho de 2017 22:21:10 PDT Giovanni Funchal
>> wrote:
>> > I agree with Daniel's point that the 1:1 relation between container and
>> > iterator types is not currently mandated. However:
>> > - I believe it only affects (3).
>>
>> Strictly speaking, yes. But (2) is also difficult to achieve. You're
>> asking for
>> a way to transform an iterator to const_iterator, but those types are
>> often
>> unrelated. For example, for libstdc++'s std::unordered_map, the two
>> iterator
>> classes are just aliases to std::__detail::_Node_const_iterator and
>> std::__detail::_Node_iterator.
>>
>> A const iterator is not the same as a const_iterator.
>>
>> > - Due to std::iterator_traits<iterator>, iterators know something
>> about
>> > their container (iterator_category) so there is already limited scope
>> for
>> > an iterator to be used in multiple containers. BTW, perhaps
>> > std::iterator_traits<iterator>::iterator_container would be a better
>> place
>> > for (3).
>>
>> First, the category is the category of the iterator, not of the
>> container.
>> Second, you cannot have a link back to the container, period. (3) is
>> simply
>> unachievable. Just think of this, what should this be
>>
>>         std::iterator_traits<char *>::container
>>
>> choose:
>>         std::vector<char>
>>         std::string
>>                 std::basic_string<char, any trait, any allocator>
>> really...
>>         std::array<char, N>
>>         QVector<char>
>>         QByteArray
>>
>
> Even better, what about iterators that do not have containers? Things like
> iterator wrappers and mutators.
>
> No algorithm has any right to query anything about the iterator's
> container. That's the whole point of iterators: to be the intermediary
> between the container of the data and the algorithm that acts on the data.
> If there is something lacking in our iterator interfaces which algorithms
> genuinely need, then *that* is what needs to be fixed.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/KQII_ogpfxo/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6e2d133b-1c0a-49a9-
> ae2b-98d82d3a40d3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAKDaRu%2BvD5_rbhJw%3DdcjYC2X4BOHVpgAjb6sM%3DuGn0QvdzmD3Q%40mail.gmail.com.

--94eb2c12542a25a35205541048b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Thanks Thiago, Nicol, those are som=
e very good points and I now think like you that (3) was a bad idea, but I =
still think proposals (1) and (2) might make sense to propose as additions.=
</div><div><br></div><div><span style=3D"font-size:12.8px">&gt; Just try:</=
span><br style=3D"font-size:12.8px"><br></div><div>This works:</div><div><b=
r></div><div>void f(std::unordered_map&lt;int, int&gt;::const_iterator) {}<=
br></div><div><div>void g(std::unordered_map&lt;int, int&gt;::iterator it)<=
br></div><div>{</div><div>=C2=A0 =C2=A0 f(static_cast&lt;std::unordered_map=
&lt;int, int&gt;::const_iterator&gt;(it));</div><div>}</div><div><br></div>=
<div>(this conversion is a container requirement)</div><div><br></div><div>=
Granted it is not trivial to implement std::make_const_iterator so that it =
deduces the type to cast to, but I think disregarding implementation for on=
e second that this just points out how useful this feature would be if g() =
needed a const_iterator for whatever reason, exactly because a const_iterat=
or is not a const iterator.</div><div><br></div><div>Furthermore, one way I=
 like to reason about this is making the table below which illustrates the =
asymmetry in available functionality:</div><div><br></div><div>(1) Iterator=
 type -&gt; access function templates</div><div>iterator (std::begin/std::e=
nd)</div><div>reverse_iterator (std::rbegin/std::rend)</div><div>const_iter=
ator (std::cbegin/std::cend)</div><div>move_iterator (Missing std::mbegin/s=
td::mend)</div><div><br></div><div>(2) Iterator type -&gt; conversion funct=
ion template</div><div>reverse_iterator (std::make_reverse_iterator)<br></d=
iv><div>const_iterator (Missing std::make_const_iterator)</div><div>move_it=
erator (std::make_move_iterator)</div><div><br></div><div>Thanks,<br></div>=
<div class=3D"gmail_extra"><div><div class=3D"gmail_signature">-- Giovanni<=
/div></div><div class=3D"gmail_signature"><br></div><div class=3D"gmail_sig=
nature"><br></div>
<br><div class=3D"gmail_quote">On Tue, Jul 11, 2017 at 3:36 PM, Nicol Bolas=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_bl=
ank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail-h5">On T=
uesday, July 11, 2017 at 2:14:08 AM UTC-4, Thiago Macieira wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">On segunda-feira, 10 de julho de 20=
17 22:21:10 PDT Giovanni Funchal wrote:
<br>&gt; I agree with Daniel&#39;s point that the 1:1 relation between cont=
ainer and
<br>&gt; iterator types is not currently mandated. However:
<br>&gt; - I believe it only affects (3).
<br>
<br>Strictly speaking, yes. But (2) is also difficult to achieve. You&#39;r=
e asking for=20
<br>a way to transform an iterator to const_iterator, but those types are o=
ften=20
<br>unrelated. For example, for libstdc++&#39;s std::unordered_map, the two=
 iterator=20
<br>classes are just aliases to std::__detail::_Node_const_ite<wbr>rator an=
d=20
<br>std::__detail::_Node_iterator.
<br>
<br>A const iterator is not the same as a const_iterator.
<br>
<br>&gt; - Due to std::iterator_traits&lt;iterator&gt;<wbr>, iterators know=
 something about
<br>&gt; their container (iterator_category) so there is already limited sc=
ope for
<br>&gt; an iterator to be used in multiple containers. BTW, perhaps
<br>&gt; std::iterator_traits&lt;iterator&gt;<wbr>::iterator_container woul=
d be a better place
<br>&gt; for (3).
<br>
<br>First, the category is the category of the iterator, not of the contain=
er.=20
<br>Second, you cannot have a link back to the container, period. (3) is si=
mply=20
<br>unachievable. Just think of this, what should this be
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::iterator_traits&lt=
;c<wbr>har *&gt;::container
<br>
<br>choose:
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::vector&lt;char&gt;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::string
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0std::basic_str<wbr>ing&lt;char, any trait, any a=
llocator&gt; really...
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::array&lt;char, N&g=
t;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QVector&lt;char&gt;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QByteArray
<br></blockquote></div></div><div><br>Even better, what about iterators tha=
t do not have containers? Things like iterator wrappers and mutators.<br><b=
r>No algorithm has any right to query anything about the iterator&#39;s con=
tainer. That&#39;s the whole point of iterators: to be the intermediary bet=
ween the container of the data and the algorithm that acts on the data. If =
there is something lacking in our iterator interfaces which algorithms genu=
inely need, then <i>that</i> is what needs to be fixed.</div></div><span cl=
ass=3D"gmail-">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/KQII_ogpfxo/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/K=
QII_ogpfxo/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/6e2d=
133b-1c0a-49a9-<wbr>ae2b-98d82d3a40d3%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></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/CAKDaRu%2BvD5_rbhJw%3DdcjYC2X4BOHVpgA=
jb6sM%3DuGn0QvdzmD3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKDaRu%2Bv=
D5_rbhJw%3DdcjYC2X4BOHVpgAjb6sM%3DuGn0QvdzmD3Q%40mail.gmail.com</a>.<br />

--94eb2c12542a25a35205541048b0--

.

On ter=C3=A7a-feira, 11 de julho de 2017 13:09:09 PDT Giovanni Funchal wrot=
e:
> Thanks Thiago, Nicol, those are some very good points and I now think lik=
e
> you that (3) was a bad idea, but I still think proposals (1) and (2) migh=
t
> make sense to propose as additions.

Why? What value does it give?

> > Just try:
> This works:
>=20
> void f(std::unordered_map<int, int>::const_iterator) {}
> void g(std::unordered_map<int, int>::iterator it)
> {
>     f(static_cast<std::unordered_map<int, int>::const_iterator>(it));
> }

Sorry, that is not what I meant.

Let me rewrite:
void f(std::unordered_map<int, int>::const_iterator) {}

template <typename ForwardIterator>
void g(ForwardIterator it)
{
 f(std::make_const(it));
}

void h()
{
 std::unordered_map<int, int> m;
 g(m.begin());
}

Please write std::make_const such that the code above works.

> Granted it is not trivial to implement std::make_const_iterator so that i=
t
> deduces the type to cast to, but I think disregarding implementation for
> one second that this just points out how useful this feature would be if
> g() needed a const_iterator for whatever reason, exactly because a
> const_iterator is not a const iterator.

Please give us a couple of those "whatever reasons". Let's say at least 5=
=20
distinct use-cases.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.

On 2017-07-12 02:27, Thiago Macieira wrote:
> void f(std::unordered_map<int, int>::const_iterator) {}
>
> template <typename ForwardIterator>
> void g(ForwardIterator it)
> {
>  f(std::make_const(it));
> }
>
> void h()
> {
>  std::unordered_map<int, int> m;
>  g(m.begin());
> }
>
> Please write std::make_const such that the code above works.

  template <typename Key, typename Value>
  auto make_const(
    std::__detail::_Node_iterator<std::pair<const Key, Value>,
                                  false, false> iter)
    -> std::__detail::_Node_const_iterator<std::pair<const Key, Value>,
                                           false, false>
  {
    return iter;
  }

....?

Yeah, you need ugly partial specializations / overloads that depend on
implementation details... so what? At worst, there needs to be a type
trait to derive the const_iterator type given the iterator type, or
something along those lines. That doesn't seem fatal...

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9b96a13-c0c7-43cc-de3a-e993847f5f8c%40gmail.com.

.