------=_Part_5213_789450145.1532077492210
Content-Type: text/plain; charset="UTF-8"

Hi all,

I've written a proposal document and sample implementation for an `any_iterator` class template to add to the standard library, and was hoping for some feedback before I look for a paper number.

This is a type-erased class which corresponds to the C++ named requirements for the various iterator classes (OutputIterator, ForwardIterator, etc.).

This will allow developers to take advantage of physical design methodology to improve compile time and reduce dependencies between components, whilst still writing generic code only depending on the requirements that they care about.

It it is in a similar space to `std::function` in that it owns the underlying object and models a C++ named requirement (Callable for `std::function` and the iterator requirements for `std::any_iterator`).

The sample implementation and proposal can be found in this repository: https://github.com/Shaktal/any_iterator

Many thanks,
Thomas

--
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/09db196a-e818-4d7a-9af1-48f07b2f4c3d%40isocpp.org.

------=_Part_5213_789450145.1532077492210--

.

------=_Part_1825_1216433458.1532078274297
Content-Type: multipart/alternative;
 boundary="----=_Part_1826_159553791.1532078274297"

------=_Part_1826_159553791.1532078274297
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le vendredi 20 juillet 2018 11:04:52 UTC+2, Thomas Russell a =C3=A9crit :
>
> Hi all,
>
> I've written a proposal document and sample implementation for an=20
> `any_iterator` class template to add to the standard library, and was=20
> hoping for some feedback before I look for a paper number.=20
>
> This is a type-erased class which corresponds to the C++ named=20
> requirements for the various iterator classes (OutputIterator,=20
> ForwardIterator, etc.).
>
> This will allow developers to take advantage of physical design=20
> methodology to improve compile time and reduce dependencies between=20
> components, whilst still writing generic code only depending on the=20
> requirements that they care about.
>
> It it is in a similar space to `std::function` in that it owns the=20
> underlying object and models a C++ named requirement (Callable for=20
> `std::function` and the iterator requirements for `std::any_iterator`).
>
> The sample implementation and proposal can be found in this repository:=
=20
> https://github.com/Shaktal/any_iterator
>
> Many thanks,=20
> Thomas=20
>

I don't know if it would be fast enough for any real code, but that's=20
interesting.

I would also create a any_iterator_ref just to mimic std::function and=20
std::function_ref proposal. That would allow to make it faster in the most=
=20
common cases: most of the time, I expect ownership will not be needed.

--=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/a5e5d30a-cf5c-475d-94bb-ce4c92e82153%40isocpp.or=
g.

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

<div dir=3D"ltr">Le vendredi 20 juillet 2018 11:04:52 UTC+2, Thomas Russell=
 a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi all,<p>=
I&#39;ve written a proposal document and sample implementation for an `any_=
iterator` class template to add to the standard library, and was hoping for=
 some feedback before I look for a paper number. </p><p>This is a type-eras=
ed class which corresponds to the C++ named requirements for the various it=
erator classes (OutputIterator, ForwardIterator, etc.).</p><p>This will all=
ow developers to take advantage of physical design methodology to improve c=
ompile time and reduce dependencies between components, whilst still writin=
g generic code only depending on the requirements that they care about.</p>=
<p>It it is in a similar space to `std::function` in that it owns the under=
lying object and models a C++ named requirement (Callable for `std::functio=
n` and the iterator requirements for `std::any_iterator`).</p><p>The sample=
 implementation and proposal can be found in this repository: <a href=3D"ht=
tps://github.com/Shaktal/any_iterator" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2FShaktal%2Fany_iterator\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNHGx7QUQIF_kXPaiKJlkjLc-R8i9g&#39;;return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FShaktal%2Fan=
y_iterator\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGx7QUQIF_kXPaiKJlkjLc-R=
8i9g&#39;;return true;">https://github.com/Shaktal/<wbr>any_iterator</a></p=
><p>Many thanks, <br>Thomas </p></blockquote><div><br></div><div>I don&#39;=
t know if it would be fast enough for any real code, but that&#39;s interes=
ting.</div><div><br></div><div>I would also create a any_iterator_ref just =
to mimic std::function and std::function_ref proposal. That would allow to =
make it faster in the most common cases: most of the time, I expect ownersh=
ip will not be needed.<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/a5e5d30a-cf5c-475d-94bb-ce4c92e82153%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a5e5d30a-cf5c-475d-94bb-ce4c92e82153=
%40isocpp.org</a>.<br />

------=_Part_1826_159553791.1532078274297--

------=_Part_1825_1216433458.1532078274297--

.

------=_Part_5371_483668932.1532079821757
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think that in most cases, actually iterating over the range and retrievin=
g the object (or outputting the object in the case of any_output_iterator) =
will be a small part of the overall computational work of a function. The m=
ain purpose of this is to provide cleaner APIs for callers and improve comp=
ilation time.

You have a good point about having `any_iterator_ref` for symmetry with `fu=
nction_ref`, you think they should both be bundled in this proposal?=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/77dafd51-aee6-46c0-b78e-44dafe029499%40isocpp.or=
g.

------=_Part_5371_483668932.1532079821757--

.

------=_Part_5408_1108931967.1532085164149
Content-Type: multipart/alternative;
 boundary="----=_Part_5409_74950576.1532085164150"

------=_Part_5409_74950576.1532085164150
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le vendredi 20 juillet 2018 11:43:41 UTC+2, Thomas Russell a =C3=A9crit :
>
> I think that in most cases, actually iterating over the range and=20
> retrieving the object (or outputting the object in the case of=20
> any_output_iterator) will be a small part of the overall computational wo=
rk=20
> of a function. The main purpose of this is to provide cleaner APIs for=20
> callers and improve compilation time.
>
> You have a good point about having `any_iterator_ref` for symmetry with=
=20
> `function_ref`, you think they should both be bundled in this proposal?=
=20
>

 Yes, I think bundling them in the same proposal is a good idea. I don't=20
know the opinion of other people, though.

From my experience, it is actually possible to implement the owning part=20
from the reference part, and thus simplifying the implementation.

--=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/46117058-0ebc-46ac-bc52-fb83098f327a%40isocpp.or=
g.

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

<div dir=3D"ltr">Le vendredi 20 juillet 2018 11:43:41 UTC+2, Thomas Russell=
 a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I think th=
at in most cases, actually iterating over the range and retrieving the obje=
ct (or outputting the object in the case of any_output_iterator) will be a =
small part of the overall computational work of a function. The main purpos=
e of this is to provide cleaner APIs for callers and improve compilation ti=
me.<p>You have a good point about having `any_iterator_ref` for symmetry wi=
th `function_ref`, you think they should both be bundled in this proposal? =
</p></blockquote><div><br></div><div>=C2=A0Yes, I think bundling them in th=
e same proposal is a good idea. I don&#39;t know the opinion of other peopl=
e, though.</div><div><br></div><div>From my experience, it is actually poss=
ible to implement the owning part from the reference part, and thus simplif=
ying the implementation.<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/46117058-0ebc-46ac-bc52-fb83098f327a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/46117058-0ebc-46ac-bc52-fb83098f327a=
%40isocpp.org</a>.<br />

------=_Part_5409_74950576.1532085164150--

------=_Part_5408_1108931967.1532085164149--

.

------=_Part_5318_1243352391.1532093219598
Content-Type: multipart/alternative;
 boundary="----=_Part_5319_1618973395.1532093219598"

------=_Part_5319_1618973395.1532093219598
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, July 20, 2018 at 5:17:54 AM UTC-4, floria...@gmail.com wrote:
>
> Le vendredi 20 juillet 2018 11:04:52 UTC+2, Thomas Russell a =C3=A9crit :
>>
>> Hi all,
>>
>> I've written a proposal document and sample implementation for an=20
>> `any_iterator` class template to add to the standard library, and was=20
>> hoping for some feedback before I look for a paper number.=20
>>
>> This is a type-erased class which corresponds to the C++ named=20
>> requirements for the various iterator classes (OutputIterator,=20
>> ForwardIterator, etc.).
>>
>> This will allow developers to take advantage of physical design=20
>> methodology to improve compile time and reduce dependencies between=20
>> components, whilst still writing generic code only depending on the=20
>> requirements that they care about.
>>
>> It it is in a similar space to `std::function` in that it owns the=20
>> underlying object and models a C++ named requirement (Callable for=20
>> `std::function` and the iterator requirements for `std::any_iterator`).
>>
>> The sample implementation and proposal can be found in this repository:=
=20
>> https://github.com/Shaktal/any_iterator
>>
>> Many thanks,=20
>> Thomas=20
>>
>
> I don't know if it would be fast enough for any real code, but that's=20
> interesting.
>
> I would also create a any_iterator_ref just to mimic std::function and=20
> std::function_ref proposal. That would allow to make it faster in the mos=
t=20
> common cases: most of the time, I expect ownership will not be needed.
>

Actually, I think it's the opposite. You're far more likely to need=20
ownership of the iterator than of a function. Consider this:

any_iterator it =3D vec.begin();

The iterator from `begin()` is a prvalue. So if `it` doesn't take ownership=
=20
of it... nobody will. So now it's broken.=20
Because iterators are so frequently copied and passed around by value,=20
`any_iterator_ref` becomes quite dangerous.

Also, iterators *have* to be SemiRegular types; that's a requirement from=
=20
Ranges. So they're copyable. Coupled with the fact that most iterators will=
=20
be small, it makes sense that `any_iterator` would just store a copy of=20
them.

Lastly, if you're going to have `any_iterator`, you should also have=20
`any_range`, which is a range of `any_iterator`. And it might be a good=20
idea to investigate if you could provide sentinel support for=20
`any_iterator`, or if you can only do this through bounded ranges.

--=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/904aab35-44dd-4053-91d9-c02cbd4051a0%40isocpp.or=
g.

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

<div dir=3D"ltr">On Friday, July 20, 2018 at 5:17:54 AM UTC-4, floria...@gm=
ail.com 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"=
>Le vendredi 20 juillet 2018 11:04:52 UTC+2, Thomas Russell a =C3=A9crit=C2=
=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">Hi all,<p>I&#39;ve written a pr=
oposal document and sample implementation for an `any_iterator` class templ=
ate to add to the standard library, and was hoping for some feedback before=
 I look for a paper number. </p><p>This is a type-erased class which corres=
ponds to the C++ named requirements for the various iterator classes (Outpu=
tIterator, ForwardIterator, etc.).</p><p>This will allow developers to take=
 advantage of physical design methodology to improve compile time and reduc=
e dependencies between components, whilst still writing generic code only d=
epending on the requirements that they care about.</p><p>It it is in a simi=
lar space to `std::function` in that it owns the underlying object and mode=
ls a C++ named requirement (Callable for `std::function` and the iterator r=
equirements for `std::any_iterator`).</p><p>The sample implementation and p=
roposal can be found in this repository: <a href=3D"https://github.com/Shak=
tal/any_iterator" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FShakta=
l%2Fany_iterator\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGx7QUQIF_kXPaiKJl=
kjLc-R8i9g&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FShaktal%2Fany_iterator\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHGx7QUQIF_kXPaiKJlkjLc-R8i9g&#39;;return true=
;">https://github.com/Shaktal/<wbr>any_iterator</a></p><p>Many thanks, <br>=
Thomas </p></blockquote><div><br></div><div>I don&#39;t know if it would be=
 fast enough for any real code, but that&#39;s interesting.</div><div><br><=
/div><div>I would also create a any_iterator_ref just to mimic std::functio=
n and std::function_ref proposal. That would allow to make it faster in the=
 most common cases: most of the time, I expect ownership will not be needed=
..<br></div></div></blockquote><div><br></div><div>Actually, I think it&#39;=
s the opposite. You&#39;re far more likely to need ownership of the iterato=
r than of a function. Consider this:</div><div><br></div><div><div style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"=
prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">any_iterator it </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> vec</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">begin</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span></div></code></div></div><div><b=
r></div><div>The iterator from `begin()` is a prvalue. So if `it` doesn&#39=
;t take ownership of it... nobody will. So now it&#39;s broken. <br><div>Be=
cause iterators are so frequently copied and passed around by value, `any_i=
terator_ref` becomes quite dangerous.</div><div><br></div></div><div></div>=
<div>Also, iterators <i>have</i> to be SemiRegular types; that&#39;s a requ=
irement from Ranges. So they&#39;re copyable. Coupled with the fact that mo=
st iterators will be small, it makes sense that `any_iterator` would just s=
tore a copy of them.</div><div><br></div>Lastly, if you&#39;re going to hav=
e `any_iterator`, you should also have `any_range`, which is a range of `an=
y_iterator`. And it might be a good idea to investigate if you could provid=
e sentinel support for `any_iterator`, or if you can only do this through b=
ounded ranges.<br><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/904aab35-44dd-4053-91d9-c02cbd4051a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/904aab35-44dd-4053-91d9-c02cbd4051a0=
%40isocpp.org</a>.<br />

------=_Part_5319_1618973395.1532093219598--

------=_Part_5318_1243352391.1532093219598--

.

------=_Part_5395_335452449.1532094489395
Content-Type: text/plain; charset="UTF-8"

I agree that `any_iterator` is more useful than `any_iterator_ref`, and I also agree that it's likely to do more harm than good. I guess in this case the symmetry with `function` should be broken because of use-cases.

I mention `any_range` and a potential `any_sentinel` in the draft proposal, I do not think it is possible to have a standalone sentinel for any_iterator, it would have to rely on a type-erased range.

I think that `any_iterator` is independent enough to be considered alone, and intend to write a proposal for `any_range` after this, with `any_iterator` as a dependency.

Do you think this would be a good strategy?

--
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/ed8626c1-44a6-4264-b072-1b902a31582b%40isocpp.org.

------=_Part_5395_335452449.1532094489395--

.

------=_Part_5646_1124909072.1532096852801
Content-Type: multipart/alternative;
 boundary="----=_Part_5647_879110146.1532096852801"

------=_Part_5647_879110146.1532096852801
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le vendredi 20 juillet 2018 15:48:09 UTC+2, Thomas Russell a =C3=A9crit :
>
> I agree that `any_iterator` is more useful than `any_iterator_ref`, and I=
=20
> also agree that it's likely to do more harm than good. I guess in this ca=
se=20
> the symmetry with `function` should be broken because of use-cases.
>
> I mention `any_range` and a potential `any_sentinel` in the draft=20
> proposal, I do not think it is possible to have a standalone sentinel for=
=20
> any_iterator, it would have to rely on a type-erased range.
>
> I think that `any_iterator` is independent enough to be considered alone,=
=20
> and intend to write a proposal for `any_range` after this, with=20
> `any_iterator` as a dependency.
>
> Do you think this would be a good strategy?=20
>

Right, I completely forgot about the SemiRegular requirement.

@Nicol
In your example, I thought the lifetime of the temporary was extended to=20
match the lifetime of the any_iterator. But after some tests, it appears=20
that only holds for function calls.
Basically, I forgot current lifetime extension only works within a single=
=20
expression.

--=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/bac7dbff-98d0-43f0-8572-57236c9ee64f%40isocpp.or=
g.

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

<div dir=3D"ltr">Le vendredi 20 juillet 2018 15:48:09 UTC+2, Thomas Russell=
 a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I agree th=
at `any_iterator` is more useful than `any_iterator_ref`, and I also agree =
that it&#39;s likely to do more harm than good. I guess in this case the sy=
mmetry with `function` should be broken because of use-cases.<p>I mention `=
any_range` and a potential `any_sentinel` in the draft proposal, I do not t=
hink it is possible to have a standalone sentinel for any_iterator, it woul=
d have to rely on a type-erased range.</p><p>I think that `any_iterator` is=
 independent enough to be considered alone, and intend to write a proposal =
for `any_range` after this, with `any_iterator` as a dependency.</p><p>Do y=
ou think this would be a good strategy? </p></blockquote><div><br></div><di=
v>Right, I completely forgot about the SemiRegular requirement.</div><div><=
br></div><div>@Nicol<br></div>In your example, I thought the lifetime of th=
e temporary was extended to match the lifetime of the any_iterator. But aft=
er some tests, it appears that only holds for function calls.<br>Basically,=
 I forgot current lifetime extension only works within a single expression.=
<br></div>

<p></p>

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

------=_Part_5647_879110146.1532096852801--

------=_Part_5646_1124909072.1532096852801--

.

------=_Part_5586_1962646602.1532100713454
Content-Type: multipart/alternative;
 boundary="----=_Part_5587_1760712720.1532100713454"

------=_Part_5587_1760712720.1532100713454
Content-Type: text/plain; charset="UTF-8"

On Friday, July 20, 2018 at 9:48:09 AM UTC-4, Thomas Russell wrote:
>
> I agree that `any_iterator` is more useful than `any_iterator_ref`, and I
> also agree that it's likely to do more harm than good. I guess in this case
> the symmetry with `function` should be broken because of use-cases.
>
> I mention `any_range` and a potential `any_sentinel` in the draft
> proposal, I do not think it is possible to have a standalone sentinel for
> any_iterator, it would have to rely on a type-erased range.
>
> I think that `any_iterator` is independent enough to be considered alone,
> and intend to write a proposal for `any_range` after this, with
> `any_iterator` as a dependency.
>
> Do you think this would be a good strategy
>

`any_range` makes too much sense to not include in the proposal. C++ is
(slowly) moving towards considering ranges as being fundamental constructs,
so if `any_iterator` makes sense, so too does `any_range`.

I'm not sure if `any_sentinel` is even possible. Especially since it is the
sentinel type which determines (statically) which iterators it can be
sentinel's for. And you can't enumerate that list of iterator types, since
the iterator itself could be a template. For example, iostreams could
reasonably have a `stream_sentinel` that works for *all*
`istream_iterator<T>`s.

As part of `any_range`, it would be possible to pass an iterator/sentinel
pair and have the system erase both.

--
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/67765220-1841-4d05-a797-fa28915cf4eb%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 20, 2018 at 9:48:09 AM UTC-4, Thomas Russe=
ll wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I agree that `any_ite=
rator` is more useful than `any_iterator_ref`, and I also agree that it&#39=
;s likely to do more harm than good. I guess in this case the symmetry with=
 `function` should be broken because of use-cases.<p>I mention `any_range` =
and a potential `any_sentinel` in the draft proposal, I do not think it is =
possible to have a standalone sentinel for any_iterator, it would have to r=
ely on a type-erased range.</p><p>I think that `any_iterator` is independen=
t enough to be considered alone, and intend to write a proposal for `any_ra=
nge` after this, with `any_iterator` as a dependency.</p><p>Do you think th=
is would be a good strategy</p></blockquote><div><br></div><div>`any_range`=
 makes too much sense to not include in the proposal. C++ is (slowly) movin=
g towards considering ranges as being fundamental constructs, so if `any_it=
erator` makes sense, so too does `any_range`.</div><div><br></div><div>I&#3=
9;m not sure if `any_sentinel` is even possible. Especially since it is the=
 sentinel type which determines (statically) which iterators it can be sent=
inel&#39;s for. And you can&#39;t enumerate that list of iterator types, si=
nce the iterator itself could be a template. For example, iostreams could r=
easonably have a `stream_sentinel` that works for <i>all</i> `istream_itera=
tor&lt;T&gt;`s.</div><div><br></div><div>As part of `any_range`, it would b=
e possible to pass an iterator/sentinel pair and have the system erase both=
..<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/67765220-1841-4d05-a797-fa28915cf4eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67765220-1841-4d05-a797-fa28915cf4eb=
%40isocpp.org</a>.<br />

------=_Part_5587_1760712720.1532100713454--

------=_Part_5586_1962646602.1532100713454--

.

------=_Part_5771_2077103145.1532102155257
Content-Type: multipart/alternative;
 boundary="----=_Part_5772_1413182903.1532102155257"

------=_Part_5772_1413182903.1532102155257
Content-Type: text/plain; charset="UTF-8"

You may want to take a look
at https://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/any_view.hpp
and see if there's anything there you'd like to incorporate into your
proposal.

On Friday, July 20, 2018 at 8:31:53 AM UTC-7, Nicol Bolas wrote:
>
> On Friday, July 20, 2018 at 9:48:09 AM UTC-4, Thomas Russell wrote:
>>
>> I agree that `any_iterator` is more useful than `any_iterator_ref`, and I
>> also agree that it's likely to do more harm than good. I guess in this case
>> the symmetry with `function` should be broken because of use-cases.
>>
>> I mention `any_range` and a potential `any_sentinel` in the draft
>> proposal, I do not think it is possible to have a standalone sentinel for
>> any_iterator, it would have to rely on a type-erased range.
>>
>> I think that `any_iterator` is independent enough to be considered alone,
>> and intend to write a proposal for `any_range` after this, with
>> `any_iterator` as a dependency.
>>
>> Do you think this would be a good strategy
>>
>
> `any_range` makes too much sense to not include in the proposal. C++ is
> (slowly) moving towards considering ranges as being fundamental constructs,
> so if `any_iterator` makes sense, so too does `any_range`.
>
> I'm not sure if `any_sentinel` is even possible. Especially since it is
> the sentinel type which determines (statically) which iterators it can be
> sentinel's for. And you can't enumerate that list of iterator types, since
> the iterator itself could be a template. For example, iostreams could
> reasonably have a `stream_sentinel` that works for *all*
> `istream_iterator<T>`s.
>
> As part of `any_range`, it would be possible to pass an iterator/sentinel
> pair and have the system erase both.
>

--
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/4ea5034f-4fc0-415c-b1c0-99ebe27af720%40isocpp.org.

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

<div dir=3D"ltr">You may want to take a look at=C2=A0https://github.com/eri=
cniebler/range-v3/blob/master/include/range/v3/view/any_view.hpp and see if=
 there&#39;s anything there you&#39;d like to incorporate into your proposa=
l.<br><br>On Friday, July 20, 2018 at 8:31:53 AM UTC-7, Nicol Bolas wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Friday, Jul=
y 20, 2018 at 9:48:09 AM UTC-4, Thomas Russell wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">I agree that `any_iterator` is more useful than `any_iter=
ator_ref`, and I also agree that it&#39;s likely to do more harm than good.=
 I guess in this case the symmetry with `function` should be broken because=
 of use-cases.<p>I mention `any_range` and a potential `any_sentinel` in th=
e draft proposal, I do not think it is possible to have a standalone sentin=
el for any_iterator, it would have to rely on a type-erased range.</p><p>I =
think that `any_iterator` is independent enough to be considered alone, and=
 intend to write a proposal for `any_range` after this, with `any_iterator`=
 as a dependency.</p><p>Do you think this would be a good strategy</p></blo=
ckquote><div><br></div><div>`any_range` makes too much sense to not include=
 in the proposal. C++ is (slowly) moving towards considering ranges as bein=
g fundamental constructs, so if `any_iterator` makes sense, so too does `an=
y_range`.</div><div><br></div><div>I&#39;m not sure if `any_sentinel` is ev=
en possible. Especially since it is the sentinel type which determines (sta=
tically) which iterators it can be sentinel&#39;s for. And you can&#39;t en=
umerate that list of iterator types, since the iterator itself could be a t=
emplate. For example, iostreams could reasonably have a `stream_sentinel` t=
hat works for <i>all</i> `istream_iterator&lt;T&gt;`s.</div><div><br></div>=
<div>As part of `any_range`, it would be possible to pass an iterator/senti=
nel pair and have the system erase both.<br></div></div></blockquote></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/4ea5034f-4fc0-415c-b1c0-99ebe27af720%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4ea5034f-4fc0-415c-b1c0-99ebe27af720=
%40isocpp.org</a>.<br />

------=_Part_5772_1413182903.1532102155257--

------=_Part_5771_2077103145.1532102155257--

.

On 20/07/2018 10:43, Thomas Russell wrote:
> I think that in most cases, actually iterating over the range and retriev=
ing the object (or outputting the object in the case of any_output_iterator=
) will be a small part of the overall computational work of a function. The=
 main purpose of this is to provide cleaner APIs for callers and improve co=
mpilation time.

That really depends on what you try and use it for. I wrote something
very similar a few years ago (with a similar implementation, using
virtual functions), and it killed performance so badly I had to give up
on the idea for that use case.

Lots of iterator use cases are very simple algorithms, where the
iterator operations can be a significant part of the loop. You've got to
do incrementing, dereferencing and iterator comparison every loop. For
any_iterator that's 3 virtual function calls, which is a significant cost.

I've seen loops where the difference between looping using an integer
index and using operator[] vs using vector iterator has a measurable
performance difference. Likewise, using a named function as the
comparator for std::sort (which causes it to use the function pointer
specialization, even if the function is inline) is measurably slower
than using a lambda with the same body (which has a unique class type,
and thus can be completely inlined). any_iterator will have a similar
(or worse) performance impact.

That doesn't mean it's not worth having, just that you need to be clear
that this is not for any loops where performance matters.

Cheers,

Anthony

--=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/0c9df1ad-7eba-20fd-300a-acd772a5adea%40gmail.com=
..

.

------=_Part_6357_656178489.1532120704991
Content-Type: text/plain; charset="UTF-8"

Sorry Anthony, I should have been clearer; I meant that *in the intended use-case* the computational workload of the body of the loop should dwarf that of the three virtual function calls!

Do you think I should explicitly spell this out, perhaps in a "performance" subsection?

--
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/fdf9fe74-06e1-4630-987b-19b551f51175%40isocpp.org.

------=_Part_6357_656178489.1532120704991--

.

On 20/07/2018 22:05, Thomas Russell wrote:
> Sorry Anthony, I should have been clearer; I meant that *in the intended use-case* the computational workload of the body of the loop should dwarf that of the three virtual function calls!
>
> Do you think I should explicitly spell this out, perhaps in a "performance" subsection?

Yes. If you make it clear that you know what the consequences are it
will reduce discussion about that, and help people focus on whether they
think there are enough use cases where that doesn't matter. Given that a
lot of C++ is not performance-sensitive, there should be.

More examples (ideally with timing measurements) are always good.

Cheers,

Anthony

--
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/adf7a7c5-03dd-e474-6782-9645f5f44ad0%40gmail.com.

.

------=_Part_6528_2030491989.1532122424609
Content-Type: multipart/alternative;
 boundary="----=_Part_6529_872030622.1532122424609"

------=_Part_6529_872030622.1532122424609
Content-Type: text/plain; charset="UTF-8"

On Friday, July 20, 2018 at 5:12:24 PM UTC-4, Anthony Williams wrote:
>
> On 20/07/2018 22:05, Thomas Russell wrote:
> > Sorry Anthony, I should have been clearer; I meant that *in the intended
> use-case* the computational workload of the body of the loop should dwarf
> that of the three virtual function calls!
> >
> > Do you think I should explicitly spell this out, perhaps in a
> "performance" subsection?
>
> Yes. If you make it clear that you know what the consequences are it
> will reduce discussion about that, and help people focus on whether they
> think there are enough use cases where that doesn't matter. Given that a
> lot of C++ is not performance-sensitive, there should be.
>
> More examples (ideally with timing measurements) are always good.
>

It's not really a simple question of "performance-sensitive". It's a
question of what is the performance-sensitive part. For example, if I were
using a `regex_token_iterator` (or a similar type) to parse a string, the
cost of doing the regex search would almost certainly dwarf the cost of the
`any_iterator` type erasure.

So I could have an `any_range<string_view>`-based algorithm that could work
with any `string_view` source. A simple `vector<string_view>` would of
course be slower to process in this case, but passing a complex regex
tokenizer would not be significantly slower through the type-erased
interface.

--
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/27bd30ac-1ace-49d9-8b85-36f7f5cc5e33%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 20, 2018 at 5:12:24 PM UTC-4, Anthony Will=
iams wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
On 20/07/2018 22:05, Thomas Russell wrote:
<br>&gt; Sorry Anthony, I should have been clearer; I meant that *in the in=
tended use-case* the computational workload of the body of the loop should =
dwarf that of the three virtual function calls!=20
<br>&gt;=20
<br>&gt; Do you think I should explicitly spell this out, perhaps in a &quo=
t;performance&quot; subsection?
<br>
<br>Yes. If you make it clear that you know what the consequences are it
<br>will reduce discussion about that, and help people focus on whether the=
y
<br>think there are enough use cases where that doesn&#39;t matter. Given t=
hat a
<br>lot of C++ is not performance-sensitive, there should be.
<br>
<br>More examples (ideally with timing measurements) are always good.
<br></blockquote><div><br></div><div>It&#39;s not really a simple question =
of &quot;performance-sensitive&quot;. It&#39;s a question of what is the pe=
rformance-sensitive part. For example, if I were using a `regex_token_itera=
tor` (or a similar type) to parse a string, the cost of doing the regex sea=
rch would almost certainly dwarf the cost of the `any_iterator` type erasur=
e.</div><div><br></div><div>So I could have an `any_range&lt;string_view&gt=
;`-based algorithm that could work with any `string_view` source. A simple =
`vector&lt;string_view&gt;` would of course be slower to process in this ca=
se, but passing a complex regex tokenizer would not be significantly slower=
 through the type-erased interface.</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/27bd30ac-1ace-49d9-8b85-36f7f5cc5e33%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27bd30ac-1ace-49d9-8b85-36f7f5cc5e33=
%40isocpp.org</a>.<br />

------=_Part_6529_872030622.1532122424609--

------=_Part_6528_2030491989.1532122424609--

.

--000000000000e067ab05717ec300
Content-Type: text/plain; charset="UTF-8"

On Fri, 20 Jul 2018 at 11:04, Thomas Russell <thomas.russell97@gmail.com>
wrote:

> Hi all,
>
> I've written a proposal document and sample implementation for an
> `any_iterator` class template to add to the standard library, and was
> hoping for some feedback before I look for a paper number.
>
> This is a type-erased class which corresponds to the C++ named
> requirements for the various iterator classes (OutputIterator,
> ForwardIterator, etc.).
>
> This will allow developers to take advantage of physical design
> methodology to improve compile time and reduce dependencies between
> components, whilst still writing generic code only depending on the
> requirements that they care about.
>
> It it is in a similar space to `std::function` in that it owns the
> underlying object and models a C++ named requirement (Callable for
> `std::function` and the iterator requirements for `std::any_iterator`).
>
> The sample implementation and proposal can be found in this repository:
> https://github.com/Shaktal/any_iterator


The documentation does not mention a motivating use case.

If reducing compile times at the cost of runtime efficiency is the goal,
one might ask whether c++ is the correct language for the application, no?

java, .net, python, etc are all built on the foundation of type erasure.

The standard library (nee Standard Template Library) was designed from a
different viewpoint.




>
>
> Many thanks,
> Thomas
>
> --
> 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/09db196a-e818-4d7a-9af1-48f07b2f4c3d%40isocpp.org
> .
>

--
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/CALvx3hZkVPxg3E0MBPBeXnNwK9szQ5o6O7Gs2ab_omXt8R8%3Dqw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri=
, 20 Jul 2018 at 11:04, Thomas Russell &lt;<a href=3D"mailto:thomas.russell=
97@gmail.com">thomas.russell97@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">Hi all,<br>
<br>
I&#39;ve written a proposal document and sample implementation for an `any_=
iterator` class template to add to the standard library, and was hoping for=
 some feedback before I look for a paper number. <br>
<br>
This is a type-erased class which corresponds to the C++ named requirements=
 for the various iterator classes (OutputIterator, ForwardIterator, etc.).<=
br>
<br>
This will allow developers to take advantage of physical design methodology=
 to improve compile time and reduce dependencies between components, whilst=
 still writing generic code only depending on the requirements that they ca=
re about.<br>
<br>
It it is in a similar space to `std::function` in that it owns the underlyi=
ng object and models a C++ named requirement (Callable for `std::function` =
and the iterator requirements for `std::any_iterator`).<br>
<br>
The sample implementation and proposal can be found in this repository: <a =
href=3D"https://github.com/Shaktal/any_iterator" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/Shaktal/any_iterator</a></blockquote><div><b=
r></div><div>The documentation does not mention a motivating use case.</div=
><div><br></div><div>If reducing compile times at the cost of runtime effic=
iency is the goal, one might ask whether c++ is the correct language for th=
e application, no?</div><div><br></div><div>java, .net, python, etc are all=
 built on the foundation of type erasure.</div><div><br></div><div>The stan=
dard library (nee Standard Template Library) was designed from a different =
viewpoint.</div><div><br></div><div>=C2=A0</div><div>=C2=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><br>
<br>
Many thanks, <br>
Thomas <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/09db196a-e818-4d7a-9af1-48f07b2f4c3d%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/09db196a-e818-4d7a-9af1-48f07b2f4c3d%4=
0isocpp.org</a>.<br>
</blockquote></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/CALvx3hZkVPxg3E0MBPBeXnNwK9szQ5o6O7Gs=
2ab_omXt8R8%3Dqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZkVPxg3E=
0MBPBeXnNwK9szQ5o6O7Gs2ab_omXt8R8%3Dqw%40mail.gmail.com</a>.<br />

--000000000000e067ab05717ec300--

.

------=_Part_7356_571720479.1532180039555
Content-Type: multipart/alternative;
 boundary="----=_Part_7357_1909563989.1532180039555"

------=_Part_7357_1909563989.1532180039555
Content-Type: text/plain; charset="UTF-8"

On Saturday, July 21, 2018 at 5:09:11 AM UTC-4, Richard Hodges wrote:
>
> On Fri, 20 Jul 2018 at 11:04, Thomas Russell <thomas.r...@gmail.com
> <javascript:>> wrote:
>
>> Hi all,
>>
>> I've written a proposal document and sample implementation for an
>> `any_iterator` class template to add to the standard library, and was
>> hoping for some feedback before I look for a paper number.
>>
>> This is a type-erased class which corresponds to the C++ named
>> requirements for the various iterator classes (OutputIterator,
>> ForwardIterator, etc.).
>>
>> This will allow developers to take advantage of physical design
>> methodology to improve compile time and reduce dependencies between
>> components, whilst still writing generic code only depending on the
>> requirements that they care about.
>>
>> It it is in a similar space to `std::function` in that it owns the
>> underlying object and models a C++ named requirement (Callable for
>> `std::function` and the iterator requirements for `std::any_iterator`).
>>
>> The sample implementation and proposal can be found in this repository:
>> https://github.com/Shaktal/any_iterator
>
>
> The documentation does not mention a motivating use case.
>
> If reducing compile times at the cost of runtime efficiency is the goal,
> one might ask whether c++ is the correct language for the application, no?
>
> java, .net, python, etc are all built on the foundation of type erasure.
>
> The standard library (nee Standard Template Library) was designed from a
> different viewpoint.
>

The standard library is not just the STL-derived
containers/iterators/algorithms. It contains a lot of things. `any` is one
of them.

Nobody's asking to replace the entire iterator model with `any_iterator`.
The point is to have a tool, like `any`, which can work in the
circumstances where it is needed.

And it's not necessarily about compile time reduction; modules should be
able to make the distinction between template and non-template
implementations more or less meaningless for local compilation.
`any_iterator` can communicate through channels where templates can't go,
much like `any` can currently. You can pass someone a range of values
without anyone between the sending and receiving site knowing the nature of
that range. `any_iterator` can communicate across DLL/SO boundaries
(assuming both sides are using the same standard library version, of
course).

I can certainly understand the fear that new users would gravitate to the
easier-to-use tool and thus be throwing away performance. But with
concepts, and particularly terse templates, the "easier-to-use" tool isn't
nearly as easier-to-use as it used to be. Is `ForwardIterator auto it` that
much harder to type than `any_iterator it`?

--
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/24d8f121-aba9-4ead-b107-bc4b72014870%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, July 21, 2018 at 5:09:11 AM UTC-4, Richard Ho=
dges 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"><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 20 Jul 2018 at 11:04, Tho=
mas Russell &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"PrsAcL26CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">thomas.r...@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Hi all,<br>
<br>
I&#39;ve written a proposal document and sample implementation for an `any_=
iterator` class template to add to the standard library, and was hoping for=
 some feedback before I look for a paper number. <br>
<br>
This is a type-erased class which corresponds to the C++ named requirements=
 for the various iterator classes (OutputIterator, ForwardIterator, etc.).<=
br>
<br>
This will allow developers to take advantage of physical design methodology=
 to improve compile time and reduce dependencies between components, whilst=
 still writing generic code only depending on the requirements that they ca=
re about.<br>
<br>
It it is in a similar space to `std::function` in that it owns the underlyi=
ng object and models a C++ named requirement (Callable for `std::function` =
and the iterator requirements for `std::any_iterator`).<br>
<br>
The sample implementation and proposal can be found in this repository: <a =
href=3D"https://github.com/Shaktal/any_iterator" rel=3D"nofollow" target=3D=
"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dht=
tps%3A%2F%2Fgithub.com%2FShaktal%2Fany_iterator\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGx7QUQIF_kXPaiKJlkjLc-R8i9g&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FSh=
aktal%2Fany_iterator\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGx7QUQIF_kXPa=
iKJlkjLc-R8i9g&#39;;return true;">https://github.com/Shaktal/<wbr>any_itera=
tor</a></blockquote><div><br></div><div>The documentation does not mention =
a motivating use case.</div><div><br></div><div>If reducing compile times a=
t the cost of runtime efficiency is the goal, one might ask whether c++ is =
the correct language for the application, no?</div><div><br></div><div>java=
, .net, python, etc are all built on the foundation of type erasure.</div><=
div><br></div><div>The standard library (nee Standard Template Library) was=
 designed from a different viewpoint.</div></div></div></blockquote><div><b=
r></div><div>The standard library is not just the STL-derived containers/it=
erators/algorithms. It contains a lot of things. `any` is one of them.</div=
><div><br></div><div>Nobody&#39;s asking to replace the entire iterator mod=
el with `any_iterator`. The point is to have a tool, like `any`, which can =
work in the circumstances where it is needed.</div><div><br></div><div>And =
it&#39;s not necessarily about compile time reduction; modules should be ab=
le to make the distinction between template and non-template implementation=
s more or less meaningless for local compilation. `any_iterator` can commun=
icate through channels where templates can&#39;t go, much like `any` can cu=
rrently. You can pass someone a range of values without anyone between the =
sending and receiving site knowing the nature of that range. `any_iterator`=
 can communicate across DLL/SO boundaries (assuming both sides are using th=
e same standard library version, of course).</div><div><br></div><div>I can=
 certainly understand the fear that new users would gravitate to the easier=
-to-use tool and thus be throwing away performance. But with concepts, and =
particularly terse templates, the &quot;easier-to-use&quot; tool isn&#39;t =
nearly as easier-to-use as it used to be. Is `ForwardIterator auto it` that=
 much harder to type than `any_iterator it`?<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/24d8f121-aba9-4ead-b107-bc4b72014870%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24d8f121-aba9-4ead-b107-bc4b72014870=
%40isocpp.org</a>.<br />

------=_Part_7357_1909563989.1532180039555--

------=_Part_7356_571720479.1532180039555--

.

--000000000000bed2f20571828016
Content-Type: text/plain; charset="UTF-8"

On Sat, 21 Jul 2018 at 15:34, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Saturday, July 21, 2018 at 5:09:11 AM UTC-4, Richard Hodges wrote:
>>
>> On Fri, 20 Jul 2018 at 11:04, Thomas Russell <thomas.r...@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I've written a proposal document and sample implementation for an
>>> `any_iterator` class template to add to the standard library, and was
>>> hoping for some feedback before I look for a paper number.
>>>
>>> This is a type-erased class which corresponds to the C++ named
>>> requirements for the various iterator classes (OutputIterator,
>>> ForwardIterator, etc.).
>>>
>>> This will allow developers to take advantage of physical design
>>> methodology to improve compile time and reduce dependencies between
>>> components, whilst still writing generic code only depending on the
>>> requirements that they care about.
>>>
>>> It it is in a similar space to `std::function` in that it owns the
>>> underlying object and models a C++ named requirement (Callable for
>>> `std::function` and the iterator requirements for `std::any_iterator`).
>>>
>>> The sample implementation and proposal can be found in this repository:
>>> https://github.com/Shaktal/any_iterator
>>
>>
>> The documentation does not mention a motivating use case.
>>
>> If reducing compile times at the cost of runtime efficiency is the goal,
>> one might ask whether c++ is the correct language for the application, no?
>>
>> java, .net, python, etc are all built on the foundation of type erasure.
>>
>> The standard library (nee Standard Template Library) was designed from a
>> different viewpoint.
>>
>
> The standard library is not just the STL-derived
> containers/iterators/algorithms. It contains a lot of things. `any` is one
> of them.
>
> Nobody's asking to replace the entire iterator model with `any_iterator`.
> The point is to have a tool, like `any`, which can work in the
> circumstances where it is needed.
>
> And it's not necessarily about compile time reduction; modules should be
> able to make the distinction between template and non-template
> implementations more or less meaningless for local compilation.
> `any_iterator` can communicate through channels where templates can't go,
> much like `any` can currently. You can pass someone a range of values
> without anyone between the sending and receiving site knowing the nature of
> that range. `any_iterator` can communicate across DLL/SO boundaries
> (assuming both sides are using the same standard library version, of
> course).
>
> I can certainly understand the fear that new users would gravitate to the
> easier-to-use tool and thus be throwing away performance. But with
> concepts, and particularly terse templates, the "easier-to-use" tool isn't
> nearly as easier-to-use as it used to be. Is `ForwardIterator auto it` that
> much harder to type than `any_iterator it`?
>

I understand and agree with all the points you have made.

But I have yet to see a real motivating use case.



> --
> 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/24d8f121-aba9-4ead-b107-bc4b72014870%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24d8f121-aba9-4ead-b107-bc4b72014870%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/CALvx3hbfFAyh7twxd73DdPYXkrs8chxjsRL9kYzd5kk2VmgD1Q%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat=
, 21 Jul 2018 at 15:34, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.c=
om">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Saturday, July 21, 2018 at 5:09:11 AM UTC-4, Richar=
d Hodges 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"><di=
v class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 20 Jul 2018 at 11:04, Thom=
as Russell &lt;<a rel=3D"nofollow">thomas.r...@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I&#39;ve written a proposal document and sample implementation for an `any_=
iterator` class template to add to the standard library, and was hoping for=
 some feedback before I look for a paper number. <br>
<br>
This is a type-erased class which corresponds to the C++ named requirements=
 for the various iterator classes (OutputIterator, ForwardIterator, etc.).<=
br>
<br>
This will allow developers to take advantage of physical design methodology=
 to improve compile time and reduce dependencies between components, whilst=
 still writing generic code only depending on the requirements that they ca=
re about.<br>
<br>
It it is in a similar space to `std::function` in that it owns the underlyi=
ng object and models a C++ named requirement (Callable for `std::function` =
and the iterator requirements for `std::any_iterator`).<br>
<br>
The sample implementation and proposal can be found in this repository: <a =
href=3D"https://github.com/Shaktal/any_iterator" rel=3D"nofollow" target=3D=
"_blank">https://github.com/Shaktal/any_iterator</a></blockquote><div><br><=
/div><div>The documentation does not mention a motivating use case.</div><d=
iv><br></div><div>If reducing compile times at the cost of runtime efficien=
cy is the goal, one might ask whether c++ is the correct language for the a=
pplication, no?</div><div><br></div><div>java, .net, python, etc are all bu=
ilt on the foundation of type erasure.</div><div><br></div><div>The standar=
d library (nee Standard Template Library) was designed from a different vie=
wpoint.</div></div></div></blockquote><div><br></div><div>The standard libr=
ary is not just the STL-derived containers/iterators/algorithms. It contain=
s a lot of things. `any` is one of them.</div><div><br></div><div>Nobody&#3=
9;s asking to replace the entire iterator model with `any_iterator`. The po=
int is to have a tool, like `any`, which can work in the circumstances wher=
e it is needed.</div><div><br></div><div>And it&#39;s not necessarily about=
 compile time reduction; modules should be able to make the distinction bet=
ween template and non-template implementations more or less meaningless for=
 local compilation. `any_iterator` can communicate through channels where t=
emplates can&#39;t go, much like `any` can currently. You can pass someone =
a range of values without anyone between the sending and receiving site kno=
wing the nature of that range. `any_iterator` can communicate across DLL/SO=
 boundaries (assuming both sides are using the same standard library versio=
n, of course).</div><div><br></div><div>I can certainly understand the fear=
 that new users would gravitate to the easier-to-use tool and thus be throw=
ing away performance. But with concepts, and particularly terse templates, =
the &quot;easier-to-use&quot; tool isn&#39;t nearly as easier-to-use as it =
used to be. Is `ForwardIterator auto it` that much harder to type than `any=
_iterator it`?<br></div></div></blockquote><div><br></div><div>I understand=
 and agree with all the points you have made.</div><div><br></div><div>But =
I have yet to see a real motivating use case.</div><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/24d8f121-aba9-4ead-b107-bc4b72014870%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24d8f121-aba9-=
4ead-b107-bc4b72014870%40isocpp.org</a>.<br>
</blockquote></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/CALvx3hbfFAyh7twxd73DdPYXkrs8chxjsRL9=
kYzd5kk2VmgD1Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbfFAyh7twx=
d73DdPYXkrs8chxjsRL9kYzd5kk2VmgD1Q%40mail.gmail.com</a>.<br />

--000000000000bed2f20571828016--

.

------=_Part_7987_945385635.1532332884855
Content-Type: text/plain; charset="UTF-8"

The motivation is similar to having any standard type-erased facility; it gives a concrete interface that accepts an arbitrary set of classes that conform to the required concepts.

The closest existing parallel in the standard library is `std::function`, modelling the Callable concept.

Having such a facility as a vocabulary type provides various benefits over function templates accepting Callables:
- Reduced generated code-size (this can even go some way towards reducing the performance penalty).
- Works with the OOP paradigm (virtual functions cannot be function templates)
- Reduced compile-time
- Can work across dynamically-linked library boundaries, providing the correctly corresponding build parameters are met.

I think these are good motivations, but am interested to hear opposing opinions.

--
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/c9664ef6-f769-4942-8e44-56761d091efc%40isocpp.org.

------=_Part_7987_945385635.1532332884855--

.

--00000000000032dd380571a714ce
Content-Type: text/plain; charset="UTF-8"

On Mon, 23 Jul 2018 at 09:01, Thomas Russell <thomas.russell97@gmail.com>
wrote:

> The motivation is similar to having any standard type-erased facility; it
> gives a concrete interface that accepts an arbitrary set of classes that
> conform to the required concepts.
>
> The closest existing parallel in the standard library is `std::function`,
> modelling the Callable concept.
>
> Having such a facility as a vocabulary type provides various benefits over
> function templates accepting Callables:
> - Reduced generated code-size (this can even go some way towards reducing
> the performance penalty).
> - Works with the OOP paradigm (virtual functions cannot be function
> templates)
> - Reduced compile-time
> - Can work across dynamically-linked library boundaries, providing the
> correctly corresponding build parameters are met.
>
> I think these are good motivations, but am interested to hear opposing
> opinions.
>

I think it would be fair to say that they are theoretical or hypothesised
motivations, not actual concrete use cases where there is a demonstrable
benefit in providing a standardised type-erased iterator suite.

I'm thinking in terms of "here's some current software that sucks because
we don't have type-erased iterators, and presented here is a better version
using my implementation of such iterators".

I say this not to be argumentative.

I say it because like you and many others, I have played with similar ideas
because they were fun or interesting ideas. Including for example a
type-erased iterator for iterating across a tuple (operator* returns a
boost::variant of references).

However, in 30 years on and off writing commercial software, I have never
encountered an actual use case while using c++.

This is probably because I reach for c++ when seeking concrete guarantees
on type safety, and python, perl or javascript when I'm seeking type
flexibility and expressiveness.

But it could be that I am thinking myopically. I have experimented in the
past with providing more "script-like" library objects to the odd project.
Again, out of curiosity more than need.

You see what I'm saying? Is this in reality a fun personal project, or is
there a tangible benefit to me if I find this in the std toolbox?


>
> --
> 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/c9664ef6-f769-4942-8e44-56761d091efc%40isocpp.org
> .
>

--
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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 23 Jul 2018 at 09:01, Thomas Russell &lt;<a href=3D"mailto:thomas.russell=
97@gmail.com">thomas.russell97@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">The motivation is similar to having any standard type-=
erased facility; it gives a concrete interface that accepts an arbitrary se=
t of classes that conform to the required concepts.<br>
<br>
The closest existing parallel in the standard library is `std::function`, m=
odelling the Callable concept.<br>
<br>
Having such a facility as a vocabulary type provides various benefits over =
function templates accepting Callables:<br>
- Reduced generated code-size (this can even go some way towards reducing t=
he performance penalty).<br>
- Works with the OOP paradigm (virtual functions cannot be function templat=
es) <br>
- Reduced compile-time<br>
- Can work across dynamically-linked library boundaries, providing the corr=
ectly corresponding build parameters are met. <br>
<br>
I think these are good motivations, but am interested to hear opposing opin=
ions. <br></blockquote><div><br></div><div>I think it would be fair to say =
that they are theoretical or hypothesised motivations, not actual concrete =
use cases where there is a demonstrable benefit in providing a standardised=
 type-erased iterator suite.</div><div><br></div><div>I&#39;m thinking in t=
erms of &quot;here&#39;s some current software that sucks because we don&#3=
9;t have type-erased iterators, and presented here is a better version usin=
g my implementation of such iterators&quot;.</div><div><br></div><div>I say=
 this not to be argumentative.</div><div><br></div><div>I say it because li=
ke you and many others, I have played with similar ideas because they were =
fun or interesting ideas. Including for example a type-erased iterator for =
iterating across a tuple (operator* returns a boost::variant of references)=
..</div><div><br></div><div>However, in 30 years on and off writing commerci=
al software, I have never encountered an actual use case while using c++.</=
div><div><br></div><div>This is probably because I reach for c++ when seeki=
ng concrete guarantees on type safety, and python, perl or javascript when =
I&#39;m seeking type flexibility and expressiveness.</div><div><br></div><d=
iv>But it could be that I am thinking myopically. I have experimented in th=
e past with providing more &quot;script-like&quot; library objects to the o=
dd project. Again, out of curiosity more than need.=C2=A0</div><div><br></d=
iv><div>You see what I&#39;m saying? Is this in reality a fun personal proj=
ect, or is there a tangible benefit to me if I find this in the std toolbox=
?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%4=
0isocpp.org</a>.<br>
</blockquote></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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4=
md5h1WXhCR29cg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haDm01D7jCv=
JJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com</a>.<br />

--00000000000032dd380571a714ce--

.

--00000000000008f1230571ab4a87
Content-Type: text/plain; charset="UTF-8"

I've wanted type-erased iterators a few times, on various projects, various
companies.

Currently we deal with 3D points a lot.  Often in vectors.  Sometimes in
other containers.  Sometimes the 3D point is just part of a bigger struct.
So we get a vector of FooBars and each FooBar has a 3D point (or 2
different 3D points, like 'source' and 'dest' and we need to pick which we
are processing.)

For many algorithms we use, the cost of "get next point" is small compared
to other processing. And the amount of code in the algorithm is high for a
template.

So I see lots of code that copies tens of thousands of points from one
container into another, so that it is in the right format, ie so that it
can pass in a vector<Point3D>.
We might also transform each point tmp = f(*it) before processing it.  That
could also be in the iterator.



On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges <hodges.r@gmail.com> wrote:

>
>
> On Mon, 23 Jul 2018 at 09:01, Thomas Russell <thomas.russell97@gmail.com>
> wrote:
>
>> The motivation is similar to having any standard type-erased facility; it
>> gives a concrete interface that accepts an arbitrary set of classes that
>> conform to the required concepts.
>>
>> The closest existing parallel in the standard library is `std::function`,
>> modelling the Callable concept.
>>
>> Having such a facility as a vocabulary type provides various benefits
>> over function templates accepting Callables:
>> - Reduced generated code-size (this can even go some way towards reducing
>> the performance penalty).
>> - Works with the OOP paradigm (virtual functions cannot be function
>> templates)
>> - Reduced compile-time
>> - Can work across dynamically-linked library boundaries, providing the
>> correctly corresponding build parameters are met.
>>
>> I think these are good motivations, but am interested to hear opposing
>> opinions.
>>
>
> I think it would be fair to say that they are theoretical or hypothesised
> motivations, not actual concrete use cases where there is a demonstrable
> benefit in providing a standardised type-erased iterator suite.
>
> I'm thinking in terms of "here's some current software that sucks because
> we don't have type-erased iterators, and presented here is a better version
> using my implementation of such iterators".
>
> I say this not to be argumentative.
>
> I say it because like you and many others, I have played with similar
> ideas because they were fun or interesting ideas. Including for example a
> type-erased iterator for iterating across a tuple (operator* returns a
> boost::variant of references).
>
> However, in 30 years on and off writing commercial software, I have never
> encountered an actual use case while using c++.
>
> This is probably because I reach for c++ when seeking concrete guarantees
> on type safety, and python, perl or javascript when I'm seeking type
> flexibility and expressiveness.
>
> But it could be that I am thinking myopically. I have experimented in the
> past with providing more "script-like" library objects to the odd project.
> Again, out of curiosity more than need.
>
> You see what I'm saying? Is this in reality a fun personal project, or is
> there a tangible benefit to me if I find this in the std toolbox?
>
>
>>
>> --
>> 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/c9664ef6-f769-4942-
>> 8e44-56761d091efc%40isocpp.org.
>>
> --
> 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/CALvx3haDm01D7jCvJJA3JJycraXVZ
> _WHz9A4md5h1WXhCR29cg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
Tony

--
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/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com.

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

<div dir=3D"ltr"><div>I&#39;ve wanted type-erased iterators a few times, on=
 various projects, various companies.</div><div><br></div><div>Currently we=
 deal with 3D points a lot.=C2=A0 Often in vectors.=C2=A0 Sometimes in othe=
r containers.=C2=A0 Sometimes the 3D point is just part of a bigger struct.=
=C2=A0 So we get a vector of FooBars and each FooBar has a 3D point (or 2 d=
ifferent 3D points, like &#39;source&#39; and &#39;dest&#39; and we need to=
 pick which we are processing.)<br></div><div><br></div><div>For many algor=
ithms we use, the cost of &quot;get next point&quot; is small compared to o=
ther processing. And the amount of code in the algorithm is high for a temp=
late.<br></div><div><br></div><div>So I see lots of code that copies tens o=
f thousands of points from one container into another, so that it is in the=
 right format, ie so that it can pass in a vector&lt;Point3D&gt;.</div><div=
>We might also transform each point tmp =3D f(*it) before processing it.=C2=
=A0 That could also be in the iterator.<br></div><br><div><br></div><div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul 23, 201=
8 at 5:14 AM, Richard Hodges <span dir=3D"ltr">&lt;<a href=3D"mailto:hodges=
..r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"gmai=
l_quote"><span class=3D""><div dir=3D"ltr">On Mon, 23 Jul 2018 at 09:01, Th=
omas Russell &lt;<a href=3D"mailto:thomas.russell97@gmail.com" target=3D"_b=
lank">thomas.russell97@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">The motivation is similar to having any standard type-erased =
facility; it gives a concrete interface that accepts an arbitrary set of cl=
asses that conform to the required concepts.<br>
<br>
The closest existing parallel in the standard library is `std::function`, m=
odelling the Callable concept.<br>
<br>
Having such a facility as a vocabulary type provides various benefits over =
function templates accepting Callables:<br>
- Reduced generated code-size (this can even go some way towards reducing t=
he performance penalty).<br>
- Works with the OOP paradigm (virtual functions cannot be function templat=
es) <br>
- Reduced compile-time<br>
- Can work across dynamically-linked library boundaries, providing the corr=
ectly corresponding build parameters are met. <br>
<br>
I think these are good motivations, but am interested to hear opposing opin=
ions. <br></blockquote><div><br></div></span><div>I think it would be fair =
to say that they are theoretical or hypothesised motivations, not actual co=
ncrete use cases where there is a demonstrable benefit in providing a stand=
ardised type-erased iterator suite.</div><div><br></div><div>I&#39;m thinki=
ng in terms of &quot;here&#39;s some current software that sucks because we=
 don&#39;t have type-erased iterators, and presented here is a better versi=
on using my implementation of such iterators&quot;.</div><div><br></div><di=
v>I say this not to be argumentative.</div><div><br></div><div>I say it bec=
ause like you and many others, I have played with similar ideas because the=
y were fun or interesting ideas. Including for example a type-erased iterat=
or for iterating across a tuple (operator* returns a boost::variant of refe=
rences).</div><div><br></div><div>However, in 30 years on and off writing c=
ommercial software, I have never encountered an actual use case while using=
 c++.</div><div><br></div><div>This is probably because I reach for c++ whe=
n seeking concrete guarantees on type safety, and python, perl or javascrip=
t when I&#39;m seeking type flexibility and expressiveness.</div><div><br><=
/div><div>But it could be that I am thinking myopically. I have experimente=
d in the past with providing more &quot;script-like&quot; library objects t=
o the odd project. Again, out of curiosity more than need.=C2=A0</div><div>=
<br></div><div>You see what I&#39;m saying? Is this in reality a fun person=
al project, or is there a tangible benefit to me if I find this in the std =
toolbox?<br>=C2=A0<br></div><span class=3D""><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c9664ef6-f769-4942-<wbr>8e44=
-56761d091efc%40isocpp.org</a><wbr>.<br>
</blockquote></span></div></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4=
md5h1WXhCR29cg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CALvx3haDm01D7jCvJJA3JJycraXVZ<wbr>_WHz9A4md5h1WXhCR29c=
g%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></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/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgV=
nrGm5dAfy%3D%2BHnw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivaZbbS=
-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com</a>.<br />

--00000000000008f1230571ab4a87--

.

------=_Part_8297_1260973757.1532357089618
Content-Type: multipart/alternative;
 boundary="----=_Part_8298_1554985979.1532357089618"

------=_Part_8298_1554985979.1532357089618
Content-Type: text/plain; charset="UTF-8"

On Monday, July 23, 2018 at 10:16:20 AM UTC-4, Tony V E wrote:
>
> I've wanted type-erased iterators a few times, on various projects,
> various companies.
>
> Currently we deal with 3D points a lot.  Often in vectors.  Sometimes in
> other containers.  Sometimes the 3D point is just part of a bigger struct.
> So we get a vector of FooBars and each FooBar has a 3D point (or 2
> different 3D points, like 'source' and 'dest' and we need to pick which we
> are processing.)
>
> For many algorithms we use, the cost of "get next point" is small compared
> to other processing. And the amount of code in the algorithm is high for a
> template.
>
> So I see lots of code that copies tens of thousands of points from one
> container into another, so that it is in the right format, ie so that it
> can pass in a vector<Point3D>.
> We might also transform each point tmp = f(*it) before processing it.
> That could also be in the iterator.
>

Playing devil's advocate for a moment.

Consider that your codebase is in a modular C++ world. You can ship
pre-compiled module files alongside precompiled libraries; few headers need
to be delivered as part of the package. In such a world, you can make your
entire processing system templatized without having gargantuan header files
everywhere.

Given all of that, why wouldn't you simply have a template-based interface
for your processing system? That way, you can take any ForwardIterator, and
the user could use any container that offers a ForwardIterator.

Or is your goal to have a more stable DLL/SO interface to the system?

--
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/175c11b3-5c86-4626-8aff-d4c864f38015%40isocpp.org.

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

<div dir=3D"ltr">On Monday, July 23, 2018 at 10:16:20 AM UTC-4, Tony V E wr=
ote:<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>I&#3=
9;ve wanted type-erased iterators a few times, on various projects, various=
 companies.</div><div><br></div><div>Currently we deal with 3D points a lot=
..=C2=A0 Often in vectors.=C2=A0 Sometimes in other containers.=C2=A0 Someti=
mes the 3D point is just part of a bigger struct.=C2=A0 So we get a vector =
of FooBars and each FooBar has a 3D point (or 2 different 3D points, like &=
#39;source&#39; and &#39;dest&#39; and we need to pick which we are process=
ing.)<br></div><div><br></div><div>For many algorithms we use, the cost of =
&quot;get next point&quot; is small compared to other processing. And the a=
mount of code in the algorithm is high for a template.<br></div><div><br></=
div><div>So I see lots of code that copies tens of thousands of points from=
 one container into another, so that it is in the right format, ie so that =
it can pass in a vector&lt;Point3D&gt;.</div><div>We might also transform e=
ach point tmp =3D f(*it) before processing it.=C2=A0 That could also be in =
the iterator.<br></div></div></blockquote><div><br></div><div>Playing devil=
&#39;s advocate for a moment.</div><div><br></div><div>Consider that your c=
odebase is in a modular C++ world. You can ship pre-compiled module files a=
longside precompiled libraries; few headers need to be delivered as part of=
 the package. In such a world, you can make your entire processing system t=
emplatized without having gargantuan header files everywhere.</div><div><br=
></div><div>Given all of that, why wouldn&#39;t you simply have a template-=
based interface for your processing system? That way, you can take any Forw=
ardIterator, and the user could use any container that offers a ForwardIter=
ator.</div><div><br></div><div>Or is your goal to have a more stable DLL/SO=
 interface to the system?<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/175c11b3-5c86-4626-8aff-d4c864f38015%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/175c11b3-5c86-4626-8aff-d4c864f38015=
%40isocpp.org</a>.<br />

------=_Part_8298_1554985979.1532357089618--

------=_Part_8297_1260973757.1532357089618--

.

--000000000000bf05a30571abd2ef
Content-Type: text/plain; charset="UTF-8"

On Mon, 23 Jul 2018 at 16:16, Tony V E <tvaneerd@gmail.com> wrote:

> I've wanted type-erased iterators a few times, on various projects,
> various companies.
>
> Currently we deal with 3D points a lot.  Often in vectors.  Sometimes in
> other containers.  Sometimes the 3D point is just part of a bigger struct.
> So we get a vector of FooBars and each FooBar has a 3D point (or 2
> different 3D points, like 'source' and 'dest' and we need to pick which we
> are processing.)
>
> For many algorithms we use, the cost of "get next point" is small compared
> to other processing. And the amount of code in the algorithm is high for a
> template.
>
> So I see lots of code that copies tens of thousands of points from one
> container into another, so that it is in the right format, ie so that it
> can pass in a vector<Point3D>.
> We might also transform each point tmp = f(*it) before processing it.
> That could also be in the iterator.
>

This is beginning to make sense.

Now giving it more thought, I see problems.

A map's value_type is a key/value pair but a vector or set's value_type is
a value.

Conceptually we could argue that all containers have a key and a value:

vector<V> : key = std::size_t, value = V
map<K, V> : key = K, value = V
set<V> : key = V, value = V

Then we could distinguish between polymorphic key iteration and polymorphic
value iteration.

This might argue for

std::polymorphic_forward_sequence_key_view<K>,
std::polymorphic_forward_sequence_value_view<V> and
std::polymorphic_forward_sequence_key_value_view<K, V>

....etc for all classes of iterator category.

It's starting to look like a lot of work.


>
> On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>>
>>
>> On Mon, 23 Jul 2018 at 09:01, Thomas Russell <thomas.russell97@gmail.com>
>> wrote:
>>
>>> The motivation is similar to having any standard type-erased facility;
>>> it gives a concrete interface that accepts an arbitrary set of classes that
>>> conform to the required concepts.
>>>
>>> The closest existing parallel in the standard library is
>>> `std::function`, modelling the Callable concept.
>>>
>>> Having such a facility as a vocabulary type provides various benefits
>>> over function templates accepting Callables:
>>> - Reduced generated code-size (this can even go some way towards
>>> reducing the performance penalty).
>>> - Works with the OOP paradigm (virtual functions cannot be function
>>> templates)
>>> - Reduced compile-time
>>> - Can work across dynamically-linked library boundaries, providing the
>>> correctly corresponding build parameters are met.
>>>
>>> I think these are good motivations, but am interested to hear opposing
>>> opinions.
>>>
>>
>> I think it would be fair to say that they are theoretical or hypothesised
>> motivations, not actual concrete use cases where there is a demonstrable
>> benefit in providing a standardised type-erased iterator suite.
>>
>> I'm thinking in terms of "here's some current software that sucks because
>> we don't have type-erased iterators, and presented here is a better version
>> using my implementation of such iterators".
>>
>> I say this not to be argumentative.
>>
>> I say it because like you and many others, I have played with similar
>> ideas because they were fun or interesting ideas. Including for example a
>> type-erased iterator for iterating across a tuple (operator* returns a
>> boost::variant of references).
>>
>> However, in 30 years on and off writing commercial software, I have never
>> encountered an actual use case while using c++.
>>
>> This is probably because I reach for c++ when seeking concrete guarantees
>> on type safety, and python, perl or javascript when I'm seeking type
>> flexibility and expressiveness.
>>
>> But it could be that I am thinking myopically. I have experimented in the
>> past with providing more "script-like" library objects to the odd project.
>> Again, out of curiosity more than need.
>>
>> You see what I'm saying? Is this in reality a fun personal project, or is
>> there a tangible benefit to me if I find this in the std toolbox?
>>
>>
>>>
>>> --
>>> 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/c9664ef6-f769-4942-8e44-56761d091efc%40isocpp.org
>>> .
>>>
>> --
>> 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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
>
> --
> Be seeing you,
> Tony
>
> --
> 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/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com?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/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 23 Jul 2018 at 16:16, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">=
tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>I&#39;ve wanted type-erased iterators a few times, on =
various projects, various companies.</div><div><br></div><div>Currently we =
deal with 3D points a lot.=C2=A0 Often in vectors.=C2=A0 Sometimes in other=
 containers.=C2=A0 Sometimes the 3D point is just part of a bigger struct.=
=C2=A0 So we get a vector of FooBars and each FooBar has a 3D point (or 2 d=
ifferent 3D points, like &#39;source&#39; and &#39;dest&#39; and we need to=
 pick which we are processing.)<br></div><div><br></div><div>For many algor=
ithms we use, the cost of &quot;get next point&quot; is small compared to o=
ther processing. And the amount of code in the algorithm is high for a temp=
late.<br></div><div><br></div><div>So I see lots of code that copies tens o=
f thousands of points from one container into another, so that it is in the=
 right format, ie so that it can pass in a vector&lt;Point3D&gt;.</div><div=
>We might also transform each point tmp =3D f(*it) before processing it.=C2=
=A0 That could also be in the iterator.<br></div></div></blockquote><div><b=
r></div><div>This is beginning to make sense.=C2=A0</div><div><br></div><di=
v>Now giving it more thought, I see problems.</div><div><br></div><div>A ma=
p&#39;s value_type is a key/value pair but a vector or set&#39;s value_type=
 is a value.</div><div><br></div><div>Conceptually we could argue that all =
containers have a key and a value:</div><div><br></div><div><div style=3D"f=
ont-size:small;background-color:rgb(255,255,255);text-decoration-style:init=
ial;text-decoration-color:initial">vector&lt;V&gt; : key =3D std::size_t, v=
alue =3D V</div><div style=3D"font-size:small;background-color:rgb(255,255,=
255);text-decoration-style:initial;text-decoration-color:initial">map&lt;K,=
 V&gt; : key =3D K, value =3D V</div><div style=3D"font-size:small;backgrou=
nd-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-col=
or:initial">set&lt;V&gt; : key =3D V, value =3D V</div><div><br></div>Then =
we could distinguish between polymorphic key iteration and polymorphic valu=
e iteration.</div><div><br></div><div>This might argue for=C2=A0</div><div>=
<font face=3D"monospace, monospace"><br></font></div><div><font face=3D"mon=
ospace, monospace">std::polymorphic_forward_sequence_key_view&lt;K&gt;</fon=
t>,=C2=A0</div><div><span style=3D"font-size:small;background-color:rgb(255=
,255,255);text-decoration-style:initial;text-decoration-color:initial;float=
:none;display:inline"><font face=3D"monospace, monospace">std::polymorphic_=
forward_sequence_value_view&lt;V&gt;</font> and=C2=A0</span>=C2=A0</div><di=
v><font face=3D"monospace, monospace">std::polymorphic_forward_sequence_key=
_value_view&lt;K, V&gt;</font></div><div><br class=3D"gmail-Apple-interchan=
ge-newline">...etc for all classes of iterator category.</div><div>=C2=A0=
=C2=A0<br></div><div>It&#39;s starting to look like a lot of work.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>=
<div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul =
23, 2018 at 5:14 AM, Richard Hodges <span dir=3D"ltr">&lt;<a href=3D"mailto=
:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=
=3D"gmail_quote"><span><div dir=3D"ltr">On Mon, 23 Jul 2018 at 09:01, Thoma=
s Russell &lt;<a href=3D"mailto:thomas.russell97@gmail.com" target=3D"_blan=
k">thomas.russell97@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">The motivation is similar to having any standard type-erased faci=
lity; it gives a concrete interface that accepts an arbitrary set of classe=
s that conform to the required concepts.<br>
<br>
The closest existing parallel in the standard library is `std::function`, m=
odelling the Callable concept.<br>
<br>
Having such a facility as a vocabulary type provides various benefits over =
function templates accepting Callables:<br>
- Reduced generated code-size (this can even go some way towards reducing t=
he performance penalty).<br>
- Works with the OOP paradigm (virtual functions cannot be function templat=
es) <br>
- Reduced compile-time<br>
- Can work across dynamically-linked library boundaries, providing the corr=
ectly corresponding build parameters are met. <br>
<br>
I think these are good motivations, but am interested to hear opposing opin=
ions. <br></blockquote><div><br></div></span><div>I think it would be fair =
to say that they are theoretical or hypothesised motivations, not actual co=
ncrete use cases where there is a demonstrable benefit in providing a stand=
ardised type-erased iterator suite.</div><div><br></div><div>I&#39;m thinki=
ng in terms of &quot;here&#39;s some current software that sucks because we=
 don&#39;t have type-erased iterators, and presented here is a better versi=
on using my implementation of such iterators&quot;.</div><div><br></div><di=
v>I say this not to be argumentative.</div><div><br></div><div>I say it bec=
ause like you and many others, I have played with similar ideas because the=
y were fun or interesting ideas. Including for example a type-erased iterat=
or for iterating across a tuple (operator* returns a boost::variant of refe=
rences).</div><div><br></div><div>However, in 30 years on and off writing c=
ommercial software, I have never encountered an actual use case while using=
 c++.</div><div><br></div><div>This is probably because I reach for c++ whe=
n seeking concrete guarantees on type safety, and python, perl or javascrip=
t when I&#39;m seeking type flexibility and expressiveness.</div><div><br><=
/div><div>But it could be that I am thinking myopically. I have experimente=
d in the past with providing more &quot;script-like&quot; library objects t=
o the odd project. Again, out of curiosity more than need.=C2=A0</div><div>=
<br></div><div>You see what I&#39;m saying? Is this in reality a fun person=
al project, or is there a tangible benefit to me if I find this in the std =
toolbox?<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%4=
0isocpp.org</a>.<br>
</blockquote></span></div></div><span>

<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" target=3D"_=
blank">std-proposals+unsubscribe@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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4=
md5h1WXhCR29cg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com</=
a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_-502103=
8089919027371gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgV=
nrGm5dAfy%3D%2BHnw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gma=
il.com</a>.<br>
</blockquote></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/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3=
jT%3DbtXtUoUr%3Dzg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZWBkQB=
0SGDqaD5iY_-kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gmail.com</a>.<br />

--000000000000bf05a30571abd2ef--

.

--00000000000024e2950571abdc54
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 23, 2018 at 10:44 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, July 23, 2018 at 10:16:20 AM UTC-4, Tony V E wrote:
>>
>> I've wanted type-erased iterators a few times, on various projects,
>> various companies.
>>
>> Currently we deal with 3D points a lot.  Often in vectors.  Sometimes in
>> other containers.  Sometimes the 3D point is just part of a bigger struct.
>> So we get a vector of FooBars and each FooBar has a 3D point (or 2
>> different 3D points, like 'source' and 'dest' and we need to pick which we
>> are processing.)
>>
>> For many algorithms we use, the cost of "get next point" is small
>> compared to other processing. And the amount of code in the algorithm is
>> high for a template.
>>
>> So I see lots of code that copies tens of thousands of points from one
>> container into another, so that it is in the right format, ie so that it
>> can pass in a vector<Point3D>.
>> We might also transform each point tmp = f(*it) before processing it.
>> That could also be in the iterator.
>>
>
> Playing devil's advocate for a moment.
>
> Consider that your codebase is in a modular C++ world. You can ship
> pre-compiled module files alongside precompiled libraries; few headers need
> to be delivered as part of the package. In such a world, you can make your
> entire processing system templatized without having gargantuan header files
> everywhere.
>
> Given all of that, why wouldn't you simply have a template-based interface
> for your processing system? That way, you can take any ForwardIterator, and
> the user could use any container that offers a ForwardIterator.
>
> Or is your goal to have a more stable DLL/SO interface to the system?
>


I ship an exe.
So it is a question of how big do I want the exe to be.
Which, yeah, maybe it really doesn't matter.  Memory is cheap.

Probably more likely is just how much code my co-workers are comfortable
with inside a header and inside a template.
Yes, maybe modules will change that.


--
Be seeing you,
Tony

--
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/CAOHCbiu6q9p99q76AfW7LpxzGpzv7FA9375XvfYD7P9C0Z%3D46A%40mail.gmail.com.

--00000000000024e2950571abdc54
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 23, 2018 at 10:44 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><sp=
an class=3D"">On Monday, July 23, 2018 at 10:16:20 AM UTC-4, Tony V E wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I&#39;ve wan=
ted type-erased iterators a few times, on various projects, various compani=
es.</div><div><br></div><div>Currently we deal with 3D points a lot.=C2=A0 =
Often in vectors.=C2=A0 Sometimes in other containers.=C2=A0 Sometimes the =
3D point is just part of a bigger struct.=C2=A0 So we get a vector of FooBa=
rs and each FooBar has a 3D point (or 2 different 3D points, like &#39;sour=
ce&#39; and &#39;dest&#39; and we need to pick which we are processing.)<br=
></div><div><br></div><div>For many algorithms we use, the cost of &quot;ge=
t next point&quot; is small compared to other processing. And the amount of=
 code in the algorithm is high for a template.<br></div><div><br></div><div=
>So I see lots of code that copies tens of thousands of points from one con=
tainer into another, so that it is in the right format, ie so that it can p=
ass in a vector&lt;Point3D&gt;.</div><div>We might also transform each poin=
t tmp =3D f(*it) before processing it.=C2=A0 That could also be in the iter=
ator.<br></div></div></blockquote><div><br></div></span><div>Playing devil&=
#39;s advocate for a moment.</div><div><br></div><div>Consider that your co=
debase is in a modular C++ world. You can ship pre-compiled module files al=
ongside precompiled libraries; few headers need to be delivered as part of =
the package. In such a world, you can make your entire processing system te=
mplatized without having gargantuan header files everywhere.</div><div><br>=
</div><div>Given all of that, why wouldn&#39;t you simply have a template-b=
ased interface for your processing system? That way, you can take any Forwa=
rdIterator, and the user could use any container that offers a ForwardItera=
tor.</div><div><br></div><div>Or is your goal to have a more stable DLL/SO =
interface to the system?<br></div></div></blockquote><div><br></div><div><b=
r></div><div>I ship an exe.</div><div></div><div>So it is a question of how=
 big do I want the exe to be.</div><div></div><div>Which, yeah, maybe it re=
ally doesn&#39;t matter.=C2=A0 Memory is cheap.<br></div><div><br></div><di=
v>Probably more likely is just how much code my co-workers are comfortable =
with inside a header and inside a template.</div><div>Yes, maybe modules wi=
ll change that.<br></div><br clear=3D"all"></div><br>-- <br><div class=3D"g=
mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be=
 seeing you,<br></div>Tony<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/CAOHCbiu6q9p99q76AfW7LpxzGpzv7FA9375X=
vfYD7P9C0Z%3D46A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu6q9p99q=
76AfW7LpxzGpzv7FA9375XvfYD7P9C0Z%3D46A%40mail.gmail.com</a>.<br />

--00000000000024e2950571abdc54--

.

--00000000000052f7820571abed0b
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 23, 2018 at 10:54 AM, Richard Hodges <hodges.r@gmail.com> wrote:

>
>
> On Mon, 23 Jul 2018 at 16:16, Tony V E <tvaneerd@gmail.com> wrote:
>
>> I've wanted type-erased iterators a few times, on various projects,
>> various companies.
>>
>> Currently we deal with 3D points a lot.  Often in vectors.  Sometimes in
>> other containers.  Sometimes the 3D point is just part of a bigger struct.
>> So we get a vector of FooBars and each FooBar has a 3D point (or 2
>> different 3D points, like 'source' and 'dest' and we need to pick which we
>> are processing.)
>>
>> For many algorithms we use, the cost of "get next point" is small
>> compared to other processing. And the amount of code in the algorithm is
>> high for a template.
>>
>> So I see lots of code that copies tens of thousands of points from one
>> container into another, so that it is in the right format, ie so that it
>> can pass in a vector<Point3D>.
>> We might also transform each point tmp = f(*it) before processing it.
>> That could also be in the iterator.
>>
>
> This is beginning to make sense.
>
> Now giving it more thought, I see problems.
>
> A map's value_type is a key/value pair but a vector or set's value_type is
> a value.
>
> Conceptually we could argue that all containers have a key and a value:
>
> vector<V> : key = std::size_t, value = V
> map<K, V> : key = K, value = V
> set<V> : key = V, value = V
>
> Then we could distinguish between polymorphic key iteration and
> polymorphic value iteration.
>
> This might argue for
>
> std::polymorphic_forward_sequence_key_view<K>,
> std::polymorphic_forward_sequence_value_view<V> and
> std::polymorphic_forward_sequence_key_value_view<K, V>
>
> ...etc for all classes of iterator category.
>
> It's starting to look like a lot of work.
>


std::poly_sequence<T>.  If you want key, make T = key; if you want value,
make T = value; if you want key+value, make T = std::pair<key,value>.
From the point of view of the algorithm that will _use_ the iterator, it
only needs one type - whatever T it needs to process.

Put the magic of converting from map to poly_sequence<mapped_type> inside
the iterator.




>
>>
>> On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges <hodges.r@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, 23 Jul 2018 at 09:01, Thomas Russell <thomas.russell97@gmail.com>
>>> wrote:
>>>
>>>> The motivation is similar to having any standard type-erased facility;
>>>> it gives a concrete interface that accepts an arbitrary set of classes that
>>>> conform to the required concepts.
>>>>
>>>> The closest existing parallel in the standard library is
>>>> `std::function`, modelling the Callable concept.
>>>>
>>>> Having such a facility as a vocabulary type provides various benefits
>>>> over function templates accepting Callables:
>>>> - Reduced generated code-size (this can even go some way towards
>>>> reducing the performance penalty).
>>>> - Works with the OOP paradigm (virtual functions cannot be function
>>>> templates)
>>>> - Reduced compile-time
>>>> - Can work across dynamically-linked library boundaries, providing the
>>>> correctly corresponding build parameters are met.
>>>>
>>>> I think these are good motivations, but am interested to hear opposing
>>>> opinions.
>>>>
>>>
>>> I think it would be fair to say that they are theoretical or
>>> hypothesised motivations, not actual concrete use cases where there is a
>>> demonstrable benefit in providing a standardised type-erased iterator suite.
>>>
>>> I'm thinking in terms of "here's some current software that sucks
>>> because we don't have type-erased iterators, and presented here is a better
>>> version using my implementation of such iterators".
>>>
>>> I say this not to be argumentative.
>>>
>>> I say it because like you and many others, I have played with similar
>>> ideas because they were fun or interesting ideas. Including for example a
>>> type-erased iterator for iterating across a tuple (operator* returns a
>>> boost::variant of references).
>>>
>>> However, in 30 years on and off writing commercial software, I have
>>> never encountered an actual use case while using c++.
>>>
>>> This is probably because I reach for c++ when seeking concrete
>>> guarantees on type safety, and python, perl or javascript when I'm seeking
>>> type flexibility and expressiveness.
>>>
>>> But it could be that I am thinking myopically. I have experimented in
>>> the past with providing more "script-like" library objects to the odd
>>> project. Again, out of curiosity more than need.
>>>
>>> You see what I'm saying? Is this in reality a fun personal project, or
>>> is there a tangible benefit to me if I find this in the std toolbox?
>>>
>>>
>>>>
>>>> --
>>>> 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/c9664ef6-f769-4942-
>>>> 8e44-56761d091efc%40isocpp.org.
>>>>
>>> --
>>> 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/CALvx3haDm01D7jCvJJA3JJycraXVZ
>>> _WHz9A4md5h1WXhCR29cg%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>>
>> --
>> Be seeing you,
>> Tony
>>
>> --
>> 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/CAOHCbivaZbbS-
>> zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com?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/CALvx3hZWBkQB0SGDqaD5iY_-
> kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
Tony

--
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/CAOHCbisY24xBK9zEYvpaS9SLFhWwfzxLo%3DPsuFd9AncLW1VQew%40mail.gmail.com.

--00000000000052f7820571abed0b
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 23, 2018 at 10:54 AM, Richard Hodges <span dir=3D"ltr">&lt;=
<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
r><br><div class=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Mon, =
23 Jul 2018 at 16:16, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" ta=
rget=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>I&#39;ve wanted type-erased iterators =
a few times, on various projects, various companies.</div><div><br></div><d=
iv>Currently we deal with 3D points a lot.=C2=A0 Often in vectors.=C2=A0 So=
metimes in other containers.=C2=A0 Sometimes the 3D point is just part of a=
 bigger struct.=C2=A0 So we get a vector of FooBars and each FooBar has a 3=
D point (or 2 different 3D points, like &#39;source&#39; and &#39;dest&#39;=
 and we need to pick which we are processing.)<br></div><div><br></div><div=
>For many algorithms we use, the cost of &quot;get next point&quot; is smal=
l compared to other processing. And the amount of code in the algorithm is =
high for a template.<br></div><div><br></div><div>So I see lots of code tha=
t copies tens of thousands of points from one container into another, so th=
at it is in the right format, ie so that it can pass in a vector&lt;Point3D=
&gt;.</div><div>We might also transform each point tmp =3D f(*it) before pr=
ocessing it.=C2=A0 That could also be in the iterator.<br></div></div></blo=
ckquote><div><br></div></span><div>This is beginning to make sense.=C2=A0</=
div><div><br></div><div>Now giving it more thought, I see problems.</div><d=
iv><br></div><div>A map&#39;s value_type is a key/value pair but a vector o=
r set&#39;s value_type is a value.</div><div><br></div><div>Conceptually we=
 could argue that all containers have a key and a value:</div><div><br></di=
v><div><div style=3D"font-size:small;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial">vector&lt;V&gt; : =
key =3D std::size_t, value =3D V</div><div style=3D"font-size:small;backgro=
und-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-co=
lor:initial">map&lt;K, V&gt; : key =3D K, value =3D V</div><div style=3D"fo=
nt-size:small;background-color:rgb(255,255,255);text-decoration-style:initi=
al;text-decoration-color:initial">set&lt;V&gt; : key =3D V, value =3D V</di=
v><div><br></div>Then we could distinguish between polymorphic key iteratio=
n and polymorphic value iteration.</div><div><br></div><div>This might argu=
e for=C2=A0</div><div><font face=3D"monospace, monospace"><br></font></div>=
<div><font face=3D"monospace, monospace">std::polymorphic_forward_<wbr>sequ=
ence_key_view&lt;K&gt;</font>,=C2=A0</div><div><span style=3D"font-size:sma=
ll;background-color:rgb(255,255,255);text-decoration-style:initial;text-dec=
oration-color:initial;float:none;display:inline"><font face=3D"monospace, m=
onospace">std::polymorphic_forward_<wbr>sequence_value_view&lt;V&gt;</font>=
 and=C2=A0</span>=C2=A0</div><div><font face=3D"monospace, monospace">std::=
polymorphic_forward_<wbr>sequence_key_value_view&lt;K, V&gt;</font></div><d=
iv><br class=3D"m_-2938253410442622621gmail-Apple-interchange-newline">...e=
tc for all classes of iterator category.</div><div>=C2=A0=C2=A0<br></div><d=
iv>It&#39;s starting to look like a lot of work.</div></div></div></blockqu=
ote><div><br></div><div><br></div><div>std::poly_sequence&lt;T&gt;.=C2=A0 I=
f you want key, make T =3D key; if you want value, make T =3D value; if you=
 want key+value, make T =3D std::pair&lt;key,value&gt;.</div><div>
<div>From the point of view of the algorithm that will _use_ the iterator, =
it only needs one type - whatever T it needs to process.<br></div><div><br>=
 </div>

</div><div>Put the magic of converting from map to poly_sequence&lt;mapped_=
type&gt; inside the iterator.</div><div><br></div><br><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"=
ltr"><div><br></div><div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges <span dir=3D"ltr">&=
lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br><br><div class=3D"gmail_quote"><span><div dir=3D"ltr">On Mon, 23 Jul 2=
018 at 09:01, Thomas Russell &lt;<a href=3D"mailto:thomas.russell97@gmail.c=
om" target=3D"_blank">thomas.russell97@gmail.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">The motivation is similar to having any standa=
rd type-erased facility; it gives a concrete interface that accepts an arbi=
trary set of classes that conform to the required concepts.<br>
<br>
The closest existing parallel in the standard library is `std::function`, m=
odelling the Callable concept.<br>
<br>
Having such a facility as a vocabulary type provides various benefits over =
function templates accepting Callables:<br>
- Reduced generated code-size (this can even go some way towards reducing t=
he performance penalty).<br>
- Works with the OOP paradigm (virtual functions cannot be function templat=
es) <br>
- Reduced compile-time<br>
- Can work across dynamically-linked library boundaries, providing the corr=
ectly corresponding build parameters are met. <br>
<br>
I think these are good motivations, but am interested to hear opposing opin=
ions. <br></blockquote><div><br></div></span><div>I think it would be fair =
to say that they are theoretical or hypothesised motivations, not actual co=
ncrete use cases where there is a demonstrable benefit in providing a stand=
ardised type-erased iterator suite.</div><div><br></div><div>I&#39;m thinki=
ng in terms of &quot;here&#39;s some current software that sucks because we=
 don&#39;t have type-erased iterators, and presented here is a better versi=
on using my implementation of such iterators&quot;.</div><div><br></div><di=
v>I say this not to be argumentative.</div><div><br></div><div>I say it bec=
ause like you and many others, I have played with similar ideas because the=
y were fun or interesting ideas. Including for example a type-erased iterat=
or for iterating across a tuple (operator* returns a boost::variant of refe=
rences).</div><div><br></div><div>However, in 30 years on and off writing c=
ommercial software, I have never encountered an actual use case while using=
 c++.</div><div><br></div><div>This is probably because I reach for c++ whe=
n seeking concrete guarantees on type safety, and python, perl or javascrip=
t when I&#39;m seeking type flexibility and expressiveness.</div><div><br><=
/div><div>But it could be that I am thinking myopically. I have experimente=
d in the past with providing more &quot;script-like&quot; library objects t=
o the odd project. Again, out of curiosity more than need.=C2=A0</div><div>=
<br></div><div>You see what I&#39;m saying? Is this in reality a fun person=
al project, or is there a tangible benefit to me if I find this in the std =
toolbox?<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c9664ef6-f769-4942-<wbr>8e44=
-56761d091efc%40isocpp.org</a><wbr>.<br>
</blockquote></span></div></div><span>

<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" target=3D"_=
blank">std-proposals+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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4=
md5h1WXhCR29cg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CALvx3haDm01D7jCvJJA3JJycraXVZ<wbr>_WHz9A4md5h1WXhCR29c=
g%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_-293825=
3410442622621m_-5021038089919027371gmail_signature" data-smartmail=3D"gmail=
_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></d=
iv>
</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" target=3D"_=
blank">std-proposals+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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgV=
nrGm5dAfy%3D%2BHnw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAOHCbivaZbbS-<wbr>zsx4nSzs3uggAxvWSze0zgVnrGm5dA<wbr>fy=
%3D%2BHnw%40mail.gmail.com</a>.<br>
</blockquote></div></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+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/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3=
jT%3DbtXtUoUr%3Dzg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/<wbr>CALvx3hZWBkQB0SGDqaD5iY_-<wbr>kez7ibnj6wj3jT%3DbtXt=
UoUr%<wbr>3Dzg%40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<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/CAOHCbisY24xBK9zEYvpaS9SLFhWwfzxLo%3D=
PsuFd9AncLW1VQew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisY24xBK9=
zEYvpaS9SLFhWwfzxLo%3DPsuFd9AncLW1VQew%40mail.gmail.com</a>.<br />

--00000000000052f7820571abed0b--

.

On 07/23/2018 10:44 AM, Nicol Bolas wrote:
>
> Consider that your codebase is in a modular C++ world. You can ship=20
> pre-compiled module files alongside precompiled libraries; few headers=20
> need to be delivered as part of the package. In such a world, you can=20
> make your entire processing system templatized without having=20
> gargantuan header files everywhere.

None of the modules implementations currently in development will=20
support distribution of pre-compiled modules.=C2=A0 Such distribution is no=
t,=20
and never has been, a goal of the modules work.

Tom.

--=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/7b4137a8-6055-aefb-83c8-3fb9c80cc2fe%40honermann=
..net.

.

--000000000000b0f5680571acb0af
Content-Type: text/plain; charset="UTF-8"

On Mon, 23 Jul 2018 at 17:02, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Mon, Jul 23, 2018 at 10:54 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>>
>>
>> On Mon, 23 Jul 2018 at 16:16, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>> I've wanted type-erased iterators a few times, on various projects,
>>> various companies.
>>>
>>> Currently we deal with 3D points a lot.  Often in vectors.  Sometimes in
>>> other containers.  Sometimes the 3D point is just part of a bigger struct.
>>> So we get a vector of FooBars and each FooBar has a 3D point (or 2
>>> different 3D points, like 'source' and 'dest' and we need to pick which we
>>> are processing.)
>>>
>>> For many algorithms we use, the cost of "get next point" is small
>>> compared to other processing. And the amount of code in the algorithm is
>>> high for a template.
>>>
>>> So I see lots of code that copies tens of thousands of points from one
>>> container into another, so that it is in the right format, ie so that it
>>> can pass in a vector<Point3D>.
>>> We might also transform each point tmp = f(*it) before processing it.
>>> That could also be in the iterator.
>>>
>>
>> This is beginning to make sense.
>>
>> Now giving it more thought, I see problems.
>>
>> A map's value_type is a key/value pair but a vector or set's value_type
>> is a value.
>>
>> Conceptually we could argue that all containers have a key and a value:
>>
>> vector<V> : key = std::size_t, value = V
>> map<K, V> : key = K, value = V
>> set<V> : key = V, value = V
>>
>> Then we could distinguish between polymorphic key iteration and
>> polymorphic value iteration.
>>
>> This might argue for
>>
>> std::polymorphic_forward_sequence_key_view<K>,
>> std::polymorphic_forward_sequence_value_view<V> and
>> std::polymorphic_forward_sequence_key_value_view<K, V>
>>
>> ...etc for all classes of iterator category.
>>
>> It's starting to look like a lot of work.
>>
>
>
> std::poly_sequence<T>.  If you want key, make T = key; if you want value,
> make T = value; if you want key+value, make T = std::pair<key,value>.
> From the point of view of the algorithm that will _use_ the iterator, it
> only needs one type - whatever T it needs to process.
>
> Put the magic of converting from map to poly_sequence<mapped_type> inside
> the iterator.
>

For sure, this is understood.

I am pointing out the geometric nature of the task. Each iterator type will
need to "know' whether it's dealing in keys, values or pairs. This means
three different iterator types per sequence type.

By all means we could specify which in terms of a transform template:

auto first = std::forward_iterator(my_container.begin(), std::by_key);
auto last = std::forward_iterator(my_container.end(), std::by_key);
do_something(first, last);

But this is starting to look more *boost* and less like *std* (which may
not be a bad thing, since the boost library is superior in all respects).


>
>
>
>
>>
>>>
>>> On Mon, Jul 23, 2018 at 5:14 AM, Richard Hodges <hodges.r@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, 23 Jul 2018 at 09:01, Thomas Russell <
>>>> thomas.russell97@gmail.com> wrote:
>>>>
>>>>> The motivation is similar to having any standard type-erased facility;
>>>>> it gives a concrete interface that accepts an arbitrary set of classes that
>>>>> conform to the required concepts.
>>>>>
>>>>> The closest existing parallel in the standard library is
>>>>> `std::function`, modelling the Callable concept.
>>>>>
>>>>> Having such a facility as a vocabulary type provides various benefits
>>>>> over function templates accepting Callables:
>>>>> - Reduced generated code-size (this can even go some way towards
>>>>> reducing the performance penalty).
>>>>> - Works with the OOP paradigm (virtual functions cannot be function
>>>>> templates)
>>>>> - Reduced compile-time
>>>>> - Can work across dynamically-linked library boundaries, providing the
>>>>> correctly corresponding build parameters are met.
>>>>>
>>>>> I think these are good motivations, but am interested to hear opposing
>>>>> opinions.
>>>>>
>>>>
>>>> I think it would be fair to say that they are theoretical or
>>>> hypothesised motivations, not actual concrete use cases where there is a
>>>> demonstrable benefit in providing a standardised type-erased iterator suite.
>>>>
>>>> I'm thinking in terms of "here's some current software that sucks
>>>> because we don't have type-erased iterators, and presented here is a better
>>>> version using my implementation of such iterators".
>>>>
>>>> I say this not to be argumentative.
>>>>
>>>> I say it because like you and many others, I have played with similar
>>>> ideas because they were fun or interesting ideas. Including for example a
>>>> type-erased iterator for iterating across a tuple (operator* returns a
>>>> boost::variant of references).
>>>>
>>>> However, in 30 years on and off writing commercial software, I have
>>>> never encountered an actual use case while using c++.
>>>>
>>>> This is probably because I reach for c++ when seeking concrete
>>>> guarantees on type safety, and python, perl or javascript when I'm seeking
>>>> type flexibility and expressiveness.
>>>>
>>>> But it could be that I am thinking myopically. I have experimented in
>>>> the past with providing more "script-like" library objects to the odd
>>>> project. Again, out of curiosity more than need.
>>>>
>>>> You see what I'm saying? Is this in reality a fun personal project, or
>>>> is there a tangible benefit to me if I find this in the std toolbox?
>>>>
>>>>
>>>>>
>>>>> --
>>>>> 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/c9664ef6-f769-4942-8e44-56761d091efc%40isocpp.org
>>>>> .
>>>>>
>>>> --
>>>> 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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>>
>>> --
>>> Be seeing you,
>>> Tony
>>>
>>> --
>>> 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/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gmail.com?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/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
>
> --
> Be seeing you,
> Tony
>
> --
> 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/CAOHCbisY24xBK9zEYvpaS9SLFhWwfzxLo%3DPsuFd9AncLW1VQew%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisY24xBK9zEYvpaS9SLFhWwfzxLo%3DPsuFd9AncLW1VQew%40mail.gmail.com?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/CALvx3haPmAoMBHR1SADtdELVBxyZMz_kxVScQnR2siZCMCjRSA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 23 Jul 2018 at 17:02, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">=
tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Mon, Jul 23, 2018 at 10:54 AM, Richard Hodges <span dir=3D"ltr">&lt;<=
a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br=
><br><div class=3D"gmail_quote"><span><div dir=3D"ltr">On Mon, 23 Jul 2018 =
at 16:16, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_bla=
nk">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>I&#39;ve wanted type-erased iterators a few times,=
 on various projects, various companies.</div><div><br></div><div>Currently=
 we deal with 3D points a lot.=C2=A0 Often in vectors.=C2=A0 Sometimes in o=
ther containers.=C2=A0 Sometimes the 3D point is just part of a bigger stru=
ct.=C2=A0 So we get a vector of FooBars and each FooBar has a 3D point (or =
2 different 3D points, like &#39;source&#39; and &#39;dest&#39; and we need=
 to pick which we are processing.)<br></div><div><br></div><div>For many al=
gorithms we use, the cost of &quot;get next point&quot; is small compared t=
o other processing. And the amount of code in the algorithm is high for a t=
emplate.<br></div><div><br></div><div>So I see lots of code that copies ten=
s of thousands of points from one container into another, so that it is in =
the right format, ie so that it can pass in a vector&lt;Point3D&gt;.</div><=
div>We might also transform each point tmp =3D f(*it) before processing it.=
=C2=A0 That could also be in the iterator.<br></div></div></blockquote><div=
><br></div></span><div>This is beginning to make sense.=C2=A0</div><div><br=
></div><div>Now giving it more thought, I see problems.</div><div><br></div=
><div>A map&#39;s value_type is a key/value pair but a vector or set&#39;s =
value_type is a value.</div><div><br></div><div>Conceptually we could argue=
 that all containers have a key and a value:</div><div><br></div><div><div =
style=3D"font-size:small;background-color:rgb(255,255,255);text-decoration-=
style:initial;text-decoration-color:initial">vector&lt;V&gt; : key =3D std:=
:size_t, value =3D V</div><div style=3D"font-size:small;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial"=
>map&lt;K, V&gt; : key =3D K, value =3D V</div><div style=3D"font-size:smal=
l;background-color:rgb(255,255,255);text-decoration-style:initial;text-deco=
ration-color:initial">set&lt;V&gt; : key =3D V, value =3D V</div><div><br><=
/div>Then we could distinguish between polymorphic key iteration and polymo=
rphic value iteration.</div><div><br></div><div>This might argue for=C2=A0<=
/div><div><font face=3D"monospace, monospace"><br></font></div><div><font f=
ace=3D"monospace, monospace">std::polymorphic_forward_sequence_key_view&lt;=
K&gt;</font>,=C2=A0</div><div><span style=3D"font-size:small;background-col=
or:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:ini=
tial;float:none;display:inline"><font face=3D"monospace, monospace">std::po=
lymorphic_forward_sequence_value_view&lt;V&gt;</font> and=C2=A0</span>=C2=
=A0</div><div><font face=3D"monospace, monospace">std::polymorphic_forward_=
sequence_key_value_view&lt;K, V&gt;</font></div><div><br class=3D"m_5719137=
526012311878m_-2938253410442622621gmail-Apple-interchange-newline">...etc f=
or all classes of iterator category.</div><div>=C2=A0=C2=A0<br></div><div>I=
t&#39;s starting to look like a lot of work.</div></div></div></blockquote>=
<div><br></div><div><br></div><div>std::poly_sequence&lt;T&gt;.=C2=A0 If yo=
u want key, make T =3D key; if you want value, make T =3D value; if you wan=
t key+value, make T =3D std::pair&lt;key,value&gt;.</div><div>
<div>From the point of view of the algorithm that will _use_ the iterator, =
it only needs one type - whatever T it needs to process.<br></div><div><br>=
 </div>

</div><div>Put the magic of converting from map to poly_sequence&lt;mapped_=
type&gt; inside the iterator.</div></div></div></div></blockquote><div><br>=
</div><div>For sure, this is understood.=C2=A0</div><div><br></div><div>I a=
m pointing out the geometric nature of the task. Each iterator type will ne=
ed to &quot;know&#39; whether it&#39;s dealing in keys, values or pairs. Th=
is means three different iterator types per sequence type.</div><div><br></=
div><div>By all means we could specify which in terms of a transform templa=
te:</div><div><br></div><div><div style=3D"font-size:small;background-color=
:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initi=
al"><div style=3D"text-decoration-style:initial;text-decoration-color:initi=
al"><font face=3D"monospace, monospace">auto first =3D<span>=C2=A0</span><s=
pan style=3D"font-size:small;background-color:rgb(255,255,255);text-decorat=
ion-style:initial;text-decoration-color:initial;float:none;display:inline">=
std::forward_iterator(my_container.begin(),<span>=C2=A0</span><span style=
=3D"text-decoration-style:initial;text-decoration-color:initial;float:none;=
display:inline">std::by_key</span>);</span></font></div><div style=3D"text-=
decoration-style:initial;text-decoration-color:initial"><font face=3D"monos=
pace, monospace">auto last =3D<span>=C2=A0</span><span style=3D"font-size:s=
mall;background-color:rgb(255,255,255);text-decoration-style:initial;text-d=
ecoration-color:initial;float:none;display:inline">std::forward_iterator(my=
_container.end(),<span>=C2=A0</span><span style=3D"text-decoration-style:in=
itial;text-decoration-color:initial;float:none;display:inline"><span style=
=3D"font-size:small;background-color:rgb(255,255,255);text-decoration-style=
:initial;text-decoration-color:initial;float:none;display:inline">std::by_k=
ey</span></span>);</span></font></div><font face=3D"monospace, monospace">d=
o_something(first, last);<br></font></div></div><div><br></div><div>But thi=
s is starting to look more <i>boost</i>=C2=A0and less like=C2=A0<i>std</i>=
=C2=A0(which may not be a bad thing, since the boost library is superior in=
 all respects).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br><=
/div><br><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
<div class=3D"m_5719137526012311878h5"><div dir=3D"ltr"><div><br></div><div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul 23, =
2018 at 5:14 AM, Richard Hodges <span dir=3D"ltr">&lt;<a href=3D"mailto:hod=
ges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"g=
mail_quote"><span><div dir=3D"ltr">On Mon, 23 Jul 2018 at 09:01, Thomas Rus=
sell &lt;<a href=3D"mailto:thomas.russell97@gmail.com" target=3D"_blank">th=
omas.russell97@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">The motivation is similar to having any standard type-erased facility;=
 it gives a concrete interface that accepts an arbitrary set of classes tha=
t conform to the required concepts.<br>
<br>
The closest existing parallel in the standard library is `std::function`, m=
odelling the Callable concept.<br>
<br>
Having such a facility as a vocabulary type provides various benefits over =
function templates accepting Callables:<br>
- Reduced generated code-size (this can even go some way towards reducing t=
he performance penalty).<br>
- Works with the OOP paradigm (virtual functions cannot be function templat=
es) <br>
- Reduced compile-time<br>
- Can work across dynamically-linked library boundaries, providing the corr=
ectly corresponding build parameters are met. <br>
<br>
I think these are good motivations, but am interested to hear opposing opin=
ions. <br></blockquote><div><br></div></span><div>I think it would be fair =
to say that they are theoretical or hypothesised motivations, not actual co=
ncrete use cases where there is a demonstrable benefit in providing a stand=
ardised type-erased iterator suite.</div><div><br></div><div>I&#39;m thinki=
ng in terms of &quot;here&#39;s some current software that sucks because we=
 don&#39;t have type-erased iterators, and presented here is a better versi=
on using my implementation of such iterators&quot;.</div><div><br></div><di=
v>I say this not to be argumentative.</div><div><br></div><div>I say it bec=
ause like you and many others, I have played with similar ideas because the=
y were fun or interesting ideas. Including for example a type-erased iterat=
or for iterating across a tuple (operator* returns a boost::variant of refe=
rences).</div><div><br></div><div>However, in 30 years on and off writing c=
ommercial software, I have never encountered an actual use case while using=
 c++.</div><div><br></div><div>This is probably because I reach for c++ whe=
n seeking concrete guarantees on type safety, and python, perl or javascrip=
t when I&#39;m seeking type flexibility and expressiveness.</div><div><br><=
/div><div>But it could be that I am thinking myopically. I have experimente=
d in the past with providing more &quot;script-like&quot; library objects t=
o the odd project. Again, out of curiosity more than need.=C2=A0</div><div>=
<br></div><div>You see what I&#39;m saying? Is this in reality a fun person=
al project, or is there a tangible benefit to me if I find this in the std =
toolbox?<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%4=
0isocpp.org</a>.<br>
</blockquote></span></div></div><span>

<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" target=3D"_=
blank">std-proposals+unsubscribe@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/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4=
md5h1WXhCR29cg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CALvx3haDm01D7jCvJJA3JJycraXVZ_WHz9A4md5h1WXhCR29cg%40mail.gmail.com</=
a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_5719137=
526012311878m_-2938253410442622621m_-5021038089919027371gmail_signature" da=
ta-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></=
div>Tony<br></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" target=3D"_=
blank">std-proposals+unsubscribe@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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgV=
nrGm5dAfy%3D%2BHnw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAOHCbivaZbbS-zsx4nSzs3uggAxvWSze0zgVnrGm5dAfy%3D%2BHnw%40mail.gma=
il.com</a>.<br>
</blockquote></div></div><span>

<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" target=3D"_=
blank">std-proposals+unsubscribe@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/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3=
jT%3DbtXtUoUr%3Dzg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CALvx3hZWBkQB0SGDqaD5iY_-kez7ibnj6wj3jT%3DbtXtUoUr%3Dzg%40mail.gma=
il.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_5719137=
526012311878gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D=
"ltr"><div>Be seeing you,<br></div>Tony<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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbisY24xBK9zEYvpaS9SLFhWwfzxLo%3D=
PsuFd9AncLW1VQew%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAOHCbisY24xBK9zEYvpaS9SLFhWwfzxLo%3DPsuFd9AncLW1VQew%40mail.gmail.c=
om</a>.<br>
</blockquote></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/CALvx3haPmAoMBHR1SADtdELVBxyZMz_kxVSc=
QnR2siZCMCjRSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haPmAoMBHR1=
SADtdELVBxyZMz_kxVScQnR2siZCMCjRSA%40mail.gmail.com</a>.<br />

--000000000000b0f5680571acb0af--

.

------=_Part_9022_976728137.1532439521127
Content-Type: multipart/alternative;
 boundary="----=_Part_9023_201158673.1532439521127"

------=_Part_9023_201158673.1532439521127
Content-Type: text/plain; charset="UTF-8"

After went through the proposal, I think the motivation is sufficient to
me, but the design also has room for improvement.

Actually, I have been trying to design such a runtime abstraction for
containers, and the conclusion is: the semantics of C++ iterators is NOT
suitable for direct runtime polymorphism, because:
(a) it is based on the comparison, and
(b) it has complex hierarchy.

For (a), I specially looked at the semantics of `bool operator==(const
any_iterator& rhs) const` and found it not good enough both in performance
and usability.

Effects: Compares the underlying iterators of *this and rhs for equality.
> Requires: The any_iterator shall be valid and the underlying iterators of
> *this and rhs should have the same type and be equality comparable.
>

What if the underlying iterators are NOT of the same type? If it leads to
undefined behavior (as far I can tell from the "Requires" clause), the API
seems dangerous to use, especially when a function returns a value of
`any_iterator<?>`; otherwise, if the operator overload returns `false`,
there must be RTTI and will have effects on performance. Moreover, even if
the iterators are of different types, it is not necessarily ill-formed to
make comparison. For example, there is no direct comparison between
`std::vector<int>::iterator` and `std::vector<int>::const_iterator`, but
they are equality comparable because `iterator` is convertible to
`const_iterator`.

For (b), I learned about the semantics of `any_iterator
operator+(difference_type offset) const` and I think it is not friendly to
users:

Requires: The any_iterator shall be valid and upon being advanced by offset
> shall be valid; otherwise the behaviour is undefined.
>

I think it is not necessary to introduce UB here, and if there a function
that returns a value of `any_iterator<?>`, users could never write
defensive code (that is, prevent UB in advance) because there is no
"observer member functions" for this feature. Although we could add such
member functions to fix the defect, it will make the API more complex.

Actually, I am currrently working on a more generic solution for C++
polymorphism (P0957, https://wg21.link/p0957 ) called the "PFA", and have
just presented it to SG7 in Rapperswil. I think we could easily model
runtime abstractions for containers with the PFA -- All that we need to do
is to define a "facade", e.g.:

template <class V>
facade DataStream {
 V next();
 bool has_next() const;
};

.... then we can design types having specific facade, e.g., with iterators
or with other data structures. Finally, we could manage different types
with facade `DataStream` with a proxy with value-semantics or
reference-semantics.

The facade template `DataStream` is one of my illustrative examples for the
PFA, the implementation could be found at:
https://github.com/wmx16835/cpp_pfa/blob/master/test/data_stream.cc ,It
compiles with latest gcc, clang and msvc. This repository contains the
sample implementation for the next revision, but I have not yet completed
the corresponding paper. The update is mainly under performance
considerations, based on P1144 (the concept of "Trivially Relocation") and
the "Memory Allocator"
(https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/iw3JRVF8EPk
, I have not yet done that paper either).

Mingxin Wang

--
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/cb65bf14-e300-44bf-a093-8d184bb8c7d4%40isocpp.org.

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

<div dir=3D"ltr"><div>After went through the proposal, I think the motivati=
on is sufficient to me, but the design also has room for improvement.</div>=
<div><br></div><div>Actually, I have been trying to design such a runtime a=
bstraction for containers, and the conclusion is: the semantics of C++ iter=
ators is NOT suitable for direct runtime polymorphism, because:</div><div>(=
a) it is based on the comparison, and</div><div>(b) it has complex hierarch=
y.</div><div><br></div><div>For (a), I specially looked at the semantics of=
 `bool operator=3D=3D(const any_iterator&amp; rhs) const` and found it not =
good enough both in performance and usability.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: =
1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>Effects: Compares th=
e underlying iterators of *this and rhs for equality.</div><div>Requires: T=
he any_iterator shall be valid and the underlying iterators of *this and rh=
s should have the same type and be equality comparable.</div></blockquote><=
div><br></div><div>What if the underlying iterators are NOT of the same typ=
e? If it leads to undefined behavior (as far I can tell from the &quot;Requ=
ires&quot; clause), the API seems dangerous to use, especially when a funct=
ion returns a value of `any_iterator&lt;?&gt;`; otherwise, if the operator =
overload returns `false`, there must be RTTI and will have effects on perfo=
rmance. Moreover, even if the iterators are of different types, it is not n=
ecessarily ill-formed to make comparison. For example, there is no direct c=
omparison between `std::vector&lt;int&gt;::iterator` and `std::vector&lt;in=
t&gt;::const_iterator`, but they are equality comparable because `iterator`=
 is convertible to `const_iterator`.</div><div><br></div><div>For (b), I le=
arned about the semantics of `any_iterator operator+(difference_type offset=
) const` and I think it is not friendly to users:</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Requires: The any_iter=
ator shall be valid and upon being advanced by offset shall be valid; other=
wise the behaviour is undefined.<br></blockquote><div><br></div><div>I thin=
k it is not necessary to introduce UB here, and if there a function that re=
turns a value of `any_iterator&lt;?&gt;`, users could never write defensive=
 code (that is, prevent UB in advance) because there is no &quot;observer m=
ember functions&quot; for this feature. Although we could add such member f=
unctions to fix the defect, it will make the API more complex.</div><div><b=
r></div><div>Actually, I am currrently working on a more generic solution f=
or C++ polymorphism (P0957, https://wg21.link/p0957 ) called the &quot;PFA&=
quot;, and have just presented it to SG7 in Rapperswil. I think we could ea=
sily model runtime abstractions for containers with the PFA -- All that we =
need to do is to define a &quot;facade&quot;, e.g.:</div><div><br></div><di=
v><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><font face=3D"courier new, monospace"><div style=3D"background-color=
: rgb(255, 255, 255);"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> V</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span></div><div st=
yle=3D"background-color: rgb(255, 255, 255);"><span style=3D"color: #000;" =
class=3D"styled-by-prettify">facade </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">DataStream</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></div><div style=3D"background-color: rgb(255, 255=
, 255);"><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0V=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">next</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span></div=
><div style=3D"background-color: rgb(255, 255, 255);"><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> has_next</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">const</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span></div><div style=3D"background-color: rgb(255, 255, 255);"><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></fon=
t></div></code></div></div><div><br></div><div>... then we can design types=
 having specific facade, e.g., with iterators or with other data structures=
.. Finally, we could manage different types with facade `DataStream` with a =
proxy with value-semantics or reference-semantics.</div><div><br></div><div=
>The facade template `DataStream` is one of my illustrative examples for th=
e PFA, the implementation could be found at: https://github.com/wmx16835/cp=
p_pfa/blob/master/test/data_stream.cc ,It compiles with latest gcc, clang a=
nd msvc. This repository contains the sample implementation for the next re=
vision, but I have not yet completed the corresponding paper. The update is=
 mainly under performance considerations, based on P1144 (the concept of &q=
uot;Trivially Relocation&quot;) and the &quot;Memory Allocator&quot; (https=
://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/iw3JRVF8EPk ,=
 I have not yet done that paper either).</div><div><br></div><div>Mingxin W=
ang</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/cb65bf14-e300-44bf-a093-8d184bb8c7d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cb65bf14-e300-44bf-a093-8d184bb8c7d4=
%40isocpp.org</a>.<br />

------=_Part_9023_201158673.1532439521127--

------=_Part_9022_976728137.1532439521127--

.

------=_Part_9766_1958576266.1532595943997
Content-Type: multipart/alternative;
 boundary="----=_Part_9767_1493432425.1532595943997"

------=_Part_9767_1493432425.1532595943997
Content-Type: text/plain; charset="UTF-8"

 Interesting. I also have interface with exact same names for same purpose
<https://bitbucket.org/FrankHB/yslib/src/master/YBase/include/ystdex/any_iterator.hpp>
for half a decade, implemented reflecting your first alternative design. It
may count to "prior art" here. The implementation depends heavily on my
extensible `any` interface
<https://bitbucket.org/FrankHB/yslib/src/6c06490c3e2526f0685d2a00da9e76db62fac16c/YBase/include/ystdex/any.h>
(though the class itself is actually introduced earlier and being already
more extended than `std::any`). I'd like to see the reasons of preference
to the alternatives.

The motivation can be more concrete. As a fundamental facility, I find it
quite handy for GUI components in my library with some mysterious but
lightweight build blocks (combined magically like this: [1]
<https://bitbucket.org/FrankHB/yslib/src/master/YFramework/include/YSLib/UI/WidgetIteration.h>,
[2]
<https://bitbucket.org/FrankHB/yslib/src/6c06490c3e2526f0685d2a00da9e76db62fac16c/YFramework/include/YSLib/UI/Scroll.h#lines-367>,
[3]
<https://bitbucket.org/FrankHB/yslib/src/6c06490c3e2526f0685d2a00da9e76db62fac16c/YBase/include/ystdex/iterator.hpp#lines-1245>,
[4
<https://bitbucket.org/FrankHB/yslib/src/6c06490c3e2526f0685d2a00da9e76db62fac16c/YFramework/include/YSLib/UI/YWidget.h#lines-73>]).
I think it can be quite difficult to find a more suitable replacement
without magics from core language support in such case.

--
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/186595aa-30b7-4900-9d6c-8b49b6272fe0%40isocpp.org.

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

<div dir=3D"ltr">=C2=A0Interesting. I also have <a href=3D"https://bitbucke=
t.org/FrankHB/yslib/src/master/YBase/include/ystdex/any_iterator.hpp">inter=
face with exact same names for same purpose</a> for half a decade, implemen=
ted reflecting your first alternative design. It may count to &quot;prior a=
rt&quot; here. The implementation depends heavily on <a href=3D"https://bit=
bucket.org/FrankHB/yslib/src/6c06490c3e2526f0685d2a00da9e76db62fac16c/YBase=
/include/ystdex/any.h">my extensible `any` interface</a> (though the class =
itself is actually introduced earlier and being already more extended than =
`std::any`). I&#39;d like to see the reasons of preference to the alternati=
ves.<br><br>The motivation can be more concrete. As a fundamental facility,=
 I find it quite handy for GUI components in my library with some mysteriou=
s but lightweight build blocks (combined magically like this: <a href=3D"ht=
tps://bitbucket.org/FrankHB/yslib/src/master/YFramework/include/YSLib/UI/Wi=
dgetIteration.h">[1]</a>, <a href=3D"https://bitbucket.org/FrankHB/yslib/sr=
c/6c06490c3e2526f0685d2a00da9e76db62fac16c/YFramework/include/YSLib/UI/Scro=
ll.h#lines-367">[2]</a>, <a href=3D"https://bitbucket.org/FrankHB/yslib/src=
/6c06490c3e2526f0685d2a00da9e76db62fac16c/YBase/include/ystdex/iterator.hpp=
#lines-1245">[3]</a>, [<a href=3D"https://bitbucket.org/FrankHB/yslib/src/6=
c06490c3e2526f0685d2a00da9e76db62fac16c/YFramework/include/YSLib/UI/YWidget=
..h#lines-73">4</a>]). I think it can be quite difficult to find a more suit=
able replacement without magics from core language support in such case.<br=
><iframe style=3D"padding: 0px; position: absolute; top: 0px; left: 0px; wi=
dth: 1179px; height: 188px; visibility: hidden;" frameborder=3D"0"></iframe=
></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/186595aa-30b7-4900-9d6c-8b49b6272fe0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/186595aa-30b7-4900-9d6c-8b49b6272fe0=
%40isocpp.org</a>.<br />

------=_Part_9767_1493432425.1532595943997--

------=_Part_9766_1958576266.1532595943997--

.

------=_Part_9778_39179948.1532597260327
Content-Type: multipart/alternative;
 boundary="----=_Part_9779_1140722910.1532597260327"

------=_Part_9779_1140722910.1532597260327
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2018=E5=B9=B47=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=889:38:41=EF=BC=8CMingxin Wang=E5=86=99=E9=81=93=EF=BC=9A
>
> After went through the proposal, I think the motivation is sufficient to=
=20
> me, but the design also has room for improvement.
>
> Actually, I have been trying to design such a runtime abstraction for=20
> containers, and the conclusion is: the semantics of C++ iterators is NOT=
=20
> suitable for direct runtime polymorphism, because:
> (a) it is based on the comparison, and
> (b) it has complex hierarchy.
>
> For (a), I specially looked at the semantics of `bool operator=3D=3D(cons=
t=20
> any_iterator& rhs) const` and found it not good enough both in performanc=
e=20
> and usability.
>
> Effects: Compares the underlying iterators of *this and rhs for equality.
>> Requires: The any_iterator shall be valid and the underlying iterators o=
f=20
>> *this and rhs should have the same type and be equality comparable.
>>
>
> What if the underlying iterators are NOT of the same type? If it leads to=
=20
> undefined behavior (as far I can tell from the "Requires" clause), the AP=
I=20
> seems dangerous to use, especially when a function returns a value of=20
> `any_iterator<?>`; otherwise, if the operator overload returns `false`,=
=20
> there must be RTTI and will have effects on performance. Moreover, even i=
f=20
> the iterators are of different types, it is not necessarily ill-formed to=
=20
> make comparison. For example, there is no direct comparison between=20
> `std::vector<int>::iterator` and `std::vector<int>::const_iterator`, but=
=20
> they are equality comparable because `iterator` is convertible to=20
> `const_iterator`.
>
> For (b), I learned about the semantics of `any_iterator=20
> operator+(difference_type offset) const` and I think it is not friendly t=
o=20
> users:
>
> Requires: The any_iterator shall be valid and upon being advanced by=20
>> offset shall be valid; otherwise the behaviour is undefined.
>>
>
> I think it is not necessary to introduce UB here, and if there a function=
=20
> that returns a value of `any_iterator<?>`, users could never write=20
> defensive code (that is, prevent UB in advance) because there is no=20
> "observer member functions" for this feature. Although we could add such=
=20
> member functions to fix the defect, it will make the API more complex.
>
> Actually, I am currrently working on a more generic solution for C++=20
> polymorphism (P0957, https://wg21.link/p0957 ) called the "PFA", and have=
=20
> just presented it to SG7 in Rapperswil. I think we could easily model=20
> runtime abstractions for containers with the PFA -- All that we need to d=
o=20
> is to define a "facade", e.g.:
>
> template <class V>
> facade DataStream {
>  V next();
>  bool has_next() const;
> };
>
> ... then we can design types having specific facade, e.g., with iterators=
=20
> or with other data structures. Finally, we could manage different types=
=20
> with facade `DataStream` with a proxy with value-semantics or=20
> reference-semantics.
>
> The facade template `DataStream` is one of my illustrative examples for=
=20
> the PFA, the implementation could be found at:=20
> https://github.com/wmx16835/cpp_pfa/blob/master/test/data_stream.cc=20
> <https://www.google.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2Fwmx16835%2Fcpp=
_pfa%2Fblob%2Fmaster%2Ftest%2Fdata_stream.cc&sa=3DD&sntz=3D1&usg=3DAFQjCNHO=
5qTpK7dMCDpY5YjAUDfJ0hp-YQ>=20
> ,It compiles with latest gcc, clang and msvc. This repository contains th=
e=20
> sample implementation for the next revision, but I have not yet completed=
=20
> the corresponding paper. The update is mainly under performance=20
> considerations, based on P1144 (the concept of "Trivially Relocation") an=
d=20
> the "Memory Allocator" (
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/iw3JRV=
F8EPk=20
> , I have not yet done that paper either).
>
> Mingxin Wang
>

This seems has different purpose to the proposed features here. The=20
type-erased wrappers are needed to get some concrete works done by=20
providing sorts of out-of-the-box interface. You proposal provide *one of*=
=20
the means to *implement *such features. It does not imply additional=20
wrappers are useless, as they do not scale in same level. Direct relying on=
=20
your PFA would seem to be a case of over-design and premature optimization=
=20
for many more concrete problems.

Technically, there are details still not addressed in your proposal (e.g.=
=20
how would it interact with static reflection) so I don't expect it would be=
=20
implemented in a few months. Since full-featured cases in your proposal=20
involve new compiler-aided features (IIRC) users are difficult to=20
implement, I suspect there is still lack of experience to make it work for=
=20
general case intentionally.

--=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/0f1032ea-93c0-45f7-9776-b3adc51227b1%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B47=E6=9C=8824=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=889:38:41=EF=BC=8CMingxin Wang=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>After went through the proposal, I think the motivation =
is sufficient to me, but the design also has room for improvement.</div><di=
v><br></div><div>Actually, I have been trying to design such a runtime abst=
raction for containers, and the conclusion is: the semantics of C++ iterato=
rs is NOT suitable for direct runtime polymorphism, because:</div><div>(a) =
it is based on the comparison, and</div><div>(b) it has complex hierarchy.<=
/div><div><br></div><div>For (a), I specially looked at the semantics of `b=
ool operator=3D=3D(const any_iterator&amp; rhs) const` and found it not goo=
d enough both in performance and usability.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div>Effects: Compares the underlyin=
g iterators of *this and rhs for equality.</div><div>Requires: The any_iter=
ator shall be valid and the underlying iterators of *this and rhs should ha=
ve the same type and be equality comparable.</div></blockquote><div><br></d=
iv><div>What if the underlying iterators are NOT of the same type? If it le=
ads to undefined behavior (as far I can tell from the &quot;Requires&quot; =
clause), the API seems dangerous to use, especially when a function returns=
 a value of `any_iterator&lt;?&gt;`; otherwise, if the operator overload re=
turns `false`, there must be RTTI and will have effects on performance. Mor=
eover, even if the iterators are of different types, it is not necessarily =
ill-formed to make comparison. For example, there is no direct comparison b=
etween `std::vector&lt;int&gt;::iterator` and `std::vector&lt;int&gt;::cons=
t_<wbr>iterator`, but they are equality comparable because `iterator` is co=
nvertible to `const_iterator`.</div><div><br></div><div>For (b), I learned =
about the semantics of `any_iterator operator+(difference_type offset) cons=
t` and I think it is not friendly to users:</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">Requires: The any_iterator shall be =
valid and upon being advanced by offset shall be valid; otherwise the behav=
iour is undefined.<br></blockquote><div><br></div><div>I think it is not ne=
cessary to introduce UB here, and if there a function that returns a value =
of `any_iterator&lt;?&gt;`, users could never write defensive code (that is=
, prevent UB in advance) because there is no &quot;observer member function=
s&quot; for this feature. Although we could add such member functions to fi=
x the defect, it will make the API more complex.</div><div><br></div><div>A=
ctually, I am currrently working on a more generic solution for C++ polymor=
phism (P0957, <a href=3D"https://wg21.link/p0957" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dh=
ttps%3A%2F%2Fwg21.link%2Fp0957\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdpt=
JYcczvIDp0ZD4G76apo22UOw&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fwg21.link%2Fp0957\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNFdptJYcczvIDp0ZD4G76apo22UOw&#39;;return true;">h=
ttps://wg21.link/p0957</a> ) called the &quot;PFA&quot;, and have just pres=
ented it to SG7 in Rapperswil. I think we could easily model runtime abstra=
ctions for containers with the PFA -- All that we need to do is to define a=
 &quot;facade&quot;, e.g.:</div><div><br></div><div><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><font face=3D"courier new,=
 monospace"><div style=3D"background-color:rgb(255,255,255)"><span style=3D=
"color:#008">template</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span><span sty=
le=3D"color:#000"> V</span><span style=3D"color:#660">&gt;</span></div><div=
 style=3D"background-color:rgb(255,255,255)"><span style=3D"color:#000">fac=
ade </span><span style=3D"color:#606">DataStream</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">{</span></div><div style=3D"backg=
round-color:rgb(255,255,255)"><span style=3D"color:#000"> =C2=A0V </span><s=
pan style=3D"color:#008">next</span><span style=3D"color:#660">();</span></=
div><div style=3D"background-color:rgb(255,255,255)"><span style=3D"color:#=
000"> =C2=A0</span><span style=3D"color:#008">bool</span><span style=3D"col=
or:#000"> has_next</span><span style=3D"color:#660">()</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">const</span><span style=3D"=
color:#660">;</span></div><div style=3D"background-color:rgb(255,255,255)">=
<span style=3D"color:#660">};</span></div></font></div></code></div></div><=
div><br></div><div>... then we can design types having specific facade, e.g=
.., with iterators or with other data structures. Finally, we could manage d=
ifferent types with facade `DataStream` with a proxy with value-semantics o=
r reference-semantics.</div><div><br></div><div>The facade template `DataSt=
ream` is one of my illustrative examples for the PFA, the implementation co=
uld be found at: <a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgi=
thub.com%2Fwmx16835%2Fcpp_pfa%2Fblob%2Fmaster%2Ftest%2Fdata_stream.cc&amp;s=
a=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHO5qTpK7dMCDpY5YjAUDfJ0hp-YQ" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwmx16835%2Fcpp_pfa%2Fblob%2Fmaster=
%2Ftest%2Fdata_stream.cc\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHO5qTpK7dM=
CDpY5YjAUDfJ0hp-YQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwmx16835%2Fcpp_pfa%2Fblob=
%2Fmaster%2Ftest%2Fdata_stream.cc\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
O5qTpK7dMCDpY5YjAUDfJ0hp-YQ&#39;;return true;">https://github.com/wmx16835/=
<wbr>cpp_pfa/blob/master/test/data_<wbr>stream.cc</a> ,It compiles with lat=
est gcc, clang and msvc. This repository contains the sample implementation=
 for the next revision, but I have not yet completed the corresponding pape=
r. The update is mainly under performance considerations, based on P1144 (t=
he concept of &quot;Trivially Relocation&quot;) and the &quot;Memory Alloca=
tor&quot; (<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/=
std-proposals/iw3JRVF8EPk" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/s=
td-proposals/iw3JRVF8EPk&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/iw3JRVF8EPk=
&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!top=
ic/std-<wbr>proposals/iw3JRVF8EPk</a> , I have not yet done that paper eith=
er).</div><div><br></div><div>Mingxin Wang</div></div></blockquote><div><br=
>This seems has different purpose to the proposed features here. The type-e=
rased wrappers are needed to get some concrete works done by providing sort=
s of out-of-the-box interface. You proposal provide <i>one of</i> the means=
 to <i>implement </i>such features. It does not imply additional wrappers a=
re useless, as they do not scale in same level. Direct relying on your PFA =
would seem to be a case of over-design and premature optimization for many =
more concrete problems.<br><br>Technically, there are details still not add=
ressed in your proposal (e.g. how would it interact with static reflection)=
 so I don&#39;t expect it would be implemented in a few months. Since full-=
featured cases in your proposal involve new compiler-aided features (IIRC) =
users are difficult to implement, I suspect there is still lack of experien=
ce to make it work for general case intentionally.<br><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/0f1032ea-93c0-45f7-9776-b3adc51227b1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f1032ea-93c0-45f7-9776-b3adc51227b1=
%40isocpp.org</a>.<br />

------=_Part_9779_1140722910.1532597260327--

------=_Part_9778_39179948.1532597260327--

.

------=_Part_10196_1656785694.1532598848852
Content-Type: multipart/alternative;
 boundary="----=_Part_10197_1841587532.1532598848852"

------=_Part_10197_1841587532.1532598848852
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2018=E5=B9=B47=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=885:14:57=EF=BC=8CRichard Hodges=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
>
> On Mon, 23 Jul 2018 at 09:01, Thomas Russell <thomas.r...@gmail.com=20
> <javascript:>> wrote:
>
>> The motivation is similar to having any standard type-erased facility; i=
t=20
>> gives a concrete interface that accepts an arbitrary set of classes that=
=20
>> conform to the required concepts.
>>
>> The closest existing parallel in the standard library is `std::function`=
,=20
>> modelling the Callable concept.
>>
>> Having such a facility as a vocabulary type provides various benefits=20
>> over function templates accepting Callables:
>> - Reduced generated code-size (this can even go some way towards reducin=
g=20
>> the performance penalty).
>> - Works with the OOP paradigm (virtual functions cannot be function=20
>> templates)=20
>> - Reduced compile-time
>> - Can work across dynamically-linked library boundaries, providing the=
=20
>> correctly corresponding build parameters are met.=20
>>
>> I think these are good motivations, but am interested to hear opposing=
=20
>> opinions.=20
>>
>
> I think it would be fair to say that they are theoretical or hypothesised=
=20
> motivations, not actual concrete use cases where there is a demonstrable=
=20
> benefit in providing a standardised type-erased iterator suite.
>
> I'm thinking in terms of "here's some current software that sucks because=
=20
> we don't have type-erased iterators, and presented here is a better versi=
on=20
> using my implementation of such iterators".
>
> See my example posted above.
=20

> I say this not to be argumentative.
>
> I say it because like you and many others, I have played with similar=20
> ideas because they were fun or interesting ideas. Including for example a=
=20
> type-erased iterator for iterating across a tuple (operator* returns a=20
> boost::variant of references).
>
> However, in 30 years on and off writing commercial software, I have never=
=20
> encountered an actual use case while using c++.
>
> This is probably because I reach for c++ when seeking concrete guarantees=
=20
> on type safety, and python, perl or javascript when I'm seeking type=20
> flexibility and expressiveness.
>
> You are relying on static typechecking. Type safety is more than that.

And C++ itself can be no less expressive than any of dynamic language you=
=20
have mentioned. It is true there is lack of guidelines to discipline it in=
=20
a uniformed way and make it practically teachable. And it is true the=20
implementations are not expected to support such style well before it is=20
enough widely adopted. (Consider performance of template metaprogramming=20
for example.) So (currently) it does not rock in practice. But that is a=20
chicken and egg problem.

The boundary of static types and dynamic types are eliminating. Guaranteed=
=20
translation-time evaluation (`constexpr`) already make many differences=20
away by allowing more constant-expressions keeping the syntax near to the=
=20
traditional style. Libraries like boost.hana are trying to eliminate the=20
different look of computations between "meta" level and "value" level.=20
Theoretically they are similar to gradual typing in purpose, but faked (by=
=20
enforcing phase requirements). Perhaps someday we can see some real=20
mechanism of such proposed for the core language based on various field=20
experience. Better embrace it :)

But it could be that I am thinking myopically. I have experimented in the=
=20
> past with providing more "script-like" library objects to the odd project=
..=20
> Again, out of curiosity more than need.=20
>
> You see what I'm saying? Is this in reality a fun personal project, or is=
=20
> there a tangible benefit to me if I find this in the std toolbox?
> =20
>
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f7=
69-4942-8e44-56761d091efc%40isocpp.org
>> .
>>
>

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

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B47=E6=9C=8823=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=885:14:57=EF=BC=8CRichard Hodges=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, 2=
3 Jul 2018 at 09:01, Thomas Russell &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"GvY_ODdYDAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">thomas.r...@gmail.com</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">The motivation is similar to having a=
ny standard type-erased facility; it gives a concrete interface that accept=
s an arbitrary set of classes that conform to the required concepts.<br>
<br>
The closest existing parallel in the standard library is `std::function`, m=
odelling the Callable concept.<br>
<br>
Having such a facility as a vocabulary type provides various benefits over =
function templates accepting Callables:<br>
- Reduced generated code-size (this can even go some way towards reducing t=
he performance penalty).<br>
- Works with the OOP paradigm (virtual functions cannot be function templat=
es) <br>
- Reduced compile-time<br>
- Can work across dynamically-linked library boundaries, providing the corr=
ectly corresponding build parameters are met. <br>
<br>
I think these are good motivations, but am interested to hear opposing opin=
ions. <br></blockquote><div><br></div><div>I think it would be fair to say =
that they are theoretical or hypothesised motivations, not actual concrete =
use cases where there is a demonstrable benefit in providing a standardised=
 type-erased iterator suite.</div><div><br></div><div>I&#39;m thinking in t=
erms of &quot;here&#39;s some current software that sucks because we don&#3=
9;t have type-erased iterators, and presented here is a better version usin=
g my implementation of such iterators&quot;.</div><div><br></div></div></di=
v></blockquote><div>See my example posted above.<br>=C2=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_=
quote"><div></div><div>I say this not to be argumentative.</div><div><br></=
div><div>I say it because like you and many others, I have played with simi=
lar ideas because they were fun or interesting ideas. Including for example=
 a type-erased iterator for iterating across a tuple (operator* returns a b=
oost::variant of references).</div><div><br></div><div>However, in 30 years=
 on and off writing commercial software, I have never encountered an actual=
 use case while using c++.</div><div><br></div><div>This is probably becaus=
e I reach for c++ when seeking concrete guarantees on type safety, and pyth=
on, perl or javascript when I&#39;m seeking type flexibility and expressive=
ness.</div><div><br></div></div></div></blockquote><div>You are relying on =
static typechecking. Type safety is more than that.<br><br>And C++ itself c=
an be no less expressive than any of dynamic language you have mentioned. I=
t is true there is lack of guidelines to discipline it in a uniformed way a=
nd make it practically teachable. And it is true the implementations are no=
t expected to support such style well before it is enough widely adopted. (=
Consider performance of template metaprogramming for example.) So (currentl=
y) it does not rock in practice. But that is a chicken and egg problem.<br>=
<br>The boundary of static types and dynamic types are eliminating. Guarant=
eed translation-time evaluation (`constexpr`) already make many differences=
 away by allowing more constant-expressions keeping the syntax near to the =
traditional style. Libraries like boost.hana are trying to eliminate the di=
fferent look of computations between &quot;meta&quot; level and &quot;value=
&quot; level. Theoretically they are similar to gradual typing in purpose, =
but faked (by enforcing phase requirements). Perhaps someday we can see som=
e real mechanism of such proposed for the core language based on various fi=
eld experience. Better embrace it :)<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div>=
<div>But it could be that I am thinking myopically. I have experimented in =
the past with providing more &quot;script-like&quot; library objects to the=
 odd project. Again, out of curiosity more than need.=C2=A0</div><div><br><=
/div><div>You see what I&#39;m saying? Is this in reality a fun personal pr=
oject, or is there a tangible benefit to me if I find this in the std toolb=
ox?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
GvY_ODdYDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"GvY_ODdYDAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/c9664ef6-f769-4942-8e44-56761d091efc%=
40isocpp.org" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c9664e=
f6-f769-4942-8e44-56761d091efc%40isocpp.org&#39;;return true;" onclick=3D"t=
his.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposal=
s/c9664ef6-f769-4942-8e44-56761d091efc%40isocpp.org&#39;;return true;">http=
s://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c9664ef6=
-f769-4942-<wbr>8e44-56761d091efc%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
</blockquote></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/f34f99a8-b633-4c0c-b472-1f20b64f71f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f34f99a8-b633-4c0c-b472-1f20b64f71f2=
%40isocpp.org</a>.<br />

------=_Part_10197_1841587532.1532598848852--

------=_Part_10196_1656785694.1532598848852--

.

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

On Thu, 26 Jul 2018 at 11:54, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> =E5=9C=A8 2018=E5=B9=B47=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 U=
TC+8=E4=B8=8B=E5=8D=885:14:57=EF=BC=8CRichard Hodges=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>>
>>
>> On Mon, 23 Jul 2018 at 09:01, Thomas Russell <thomas.r...@gmail.com>
>> wrote:
>>
>>> The motivation is similar to having any standard type-erased facility;
>>> it gives a concrete interface that accepts an arbitrary set of classes =
that
>>> conform to the required concepts.
>>>
>>> The closest existing parallel in the standard library is
>>> `std::function`, modelling the Callable concept.
>>>
>>> Having such a facility as a vocabulary type provides various benefits
>>> over function templates accepting Callables:
>>> - Reduced generated code-size (this can even go some way towards
>>> reducing the performance penalty).
>>> - Works with the OOP paradigm (virtual functions cannot be function
>>> templates)
>>> - Reduced compile-time
>>> - Can work across dynamically-linked library boundaries, providing the
>>> correctly corresponding build parameters are met.
>>>
>>> I think these are good motivations, but am interested to hear opposing
>>> opinions.
>>>
>>
>> I think it would be fair to say that they are theoretical or hypothesise=
d
>> motivations, not actual concrete use cases where there is a demonstrable
>> benefit in providing a standardised type-erased iterator suite.
>>
>> I'm thinking in terms of "here's some current software that sucks becaus=
e
>> we don't have type-erased iterators, and presented here is a better vers=
ion
>> using my implementation of such iterators".
>>
>> See my example posted above.
>

Great, thanks.


>
>
>> I say this not to be argumentative.
>>
>> I say it because like you and many others, I have played with similar
>> ideas because they were fun or interesting ideas. Including for example =
a
>> type-erased iterator for iterating across a tuple (operator* returns a
>> boost::variant of references).
>>
>> However, in 30 years on and off writing commercial software, I have neve=
r
>> encountered an actual use case while using c++.
>>
>> This is probably because I reach for c++ when seeking concrete guarantee=
s
>> on type safety, and python, perl or javascript when I'm seeking type
>> flexibility and expressiveness.
>>
>> You are relying on static typechecking. Type safety is more than that.
>
> And C++ itself can be no less expressive than any of dynamic language you
> have mentioned. It is true there is lack of guidelines to discipline it i=
n
> a uniformed way and make it practically teachable. And it is true the
> implementations are not expected to support such style well before it is
> enough widely adopted. (Consider performance of template metaprogramming
> for example.) So (currently) it does not rock in practice. But that is a
> chicken and egg problem.
>
> The boundary of static types and dynamic types are eliminating. Guarantee=
d
> translation-time evaluation (`constexpr`) already make many differences
> away by allowing more constant-expressions keeping the syntax near to the
> traditional style. Libraries like boost.hana are trying to eliminate the
> different look of computations between "meta" level and "value" level.
> Theoretically they are similar to gradual typing in purpose, but faked (b=
y
> enforcing phase requirements). Perhaps someday we can see some real
> mechanism of such proposed for the core language based on various field
> experience. Better embrace it :)
>

Already embraced. There are some things I would like to see:

1. standardised c++ dependency manager (a-la npm, docker, cpan, pip)
2. c++ implementations required to work in interpreter mode as well as
compiler mode.
3. standardisation of the emscripten c++ -> javascript/wasm compiler.
4. standardisations of graphics, terminal, utf-8 string handling etc.

If we had that, the world would only need one language. We could achieve
more.


>
> But it could be that I am thinking myopically. I have experimented in the
>> past with providing more "script-like" library objects to the odd projec=
t.
>> Again, out of curiosity more than need.
>>
>> You see what I'm saying? Is this in reality a fun personal project, or i=
s
>> there a tangible benefit to me if I find this in the std toolbox?
>>
>>
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c9664ef6-f=
769-4942-8e44-56761d091efc%40isocpp.org
>>> .
>>>
>> --
> 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/f34f99a8-b63=
3-4c0c-b472-1f20b64f71f2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f34f99a8-b6=
33-4c0c-b472-1f20b64f71f2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CALvx3ha7PWuqYR4vc%2BR92CM3CnmHf5oGkiXsKoXVtvhXZ=
vzKYg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, 26 Jul 2018 at 11:54, FrankHB1989 &lt;<a href=3D"mailto:frankhb1989@gmail=
..com">frankhb1989@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B47=E6=9C=8823=E6=97=
=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=885:14:57=EF=BC=8CRicha=
rd Hodges=E5=86=99=E9=81=93=EF=BC=9A<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"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mo=
n, 23 Jul 2018 at 09:01, Thomas Russell &lt;<a rel=3D"nofollow">thomas.r...=
@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The moti=
vation is similar to having any standard type-erased facility; it gives a c=
oncrete interface that accepts an arbitrary set of classes that conform to =
the required concepts.<br>
<br>
The closest existing parallel in the standard library is `std::function`, m=
odelling the Callable concept.<br>
<br>
Having such a facility as a vocabulary type provides various benefits over =
function templates accepting Callables:<br>
- Reduced generated code-size (this can even go some way towards reducing t=
he performance penalty).<br>
- Works with the OOP paradigm (virtual functions cannot be function templat=
es) <br>
- Reduced compile-time<br>
- Can work across dynamically-linked library boundaries, providing the corr=
ectly corresponding build parameters are met. <br>
<br>
I think these are good motivations, but am interested to hear opposing opin=
ions. <br></blockquote><div><br></div><div>I think it would be fair to say =
that they are theoretical or hypothesised motivations, not actual concrete =
use cases where there is a demonstrable benefit in providing a standardised=
 type-erased iterator suite.</div><div><br></div><div>I&#39;m thinking in t=
erms of &quot;here&#39;s some current software that sucks because we don&#3=
9;t have type-erased iterators, and presented here is a better version usin=
g my implementation of such iterators&quot;.</div><div><br></div></div></di=
v></blockquote><div>See my example posted above.<br></div></div></blockquot=
e><div><br></div><div>Great, thanks.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><d=
iv>I say this not to be argumentative.</div><div><br></div><div>I say it be=
cause like you and many others, I have played with similar ideas because th=
ey were fun or interesting ideas. Including for example a type-erased itera=
tor for iterating across a tuple (operator* returns a boost::variant of ref=
erences).</div><div><br></div><div>However, in 30 years on and off writing =
commercial software, I have never encountered an actual use case while usin=
g c++.</div><div><br></div><div>This is probably because I reach for c++ wh=
en seeking concrete guarantees on type safety, and python, perl or javascri=
pt when I&#39;m seeking type flexibility and expressiveness.</div><div><br>=
</div></div></div></blockquote><div>You are relying on static typechecking.=
 Type safety is more than that.<br><br>And C++ itself can be no less expres=
sive than any of dynamic language you have mentioned. It is true there is l=
ack of guidelines to discipline it in a uniformed way and make it practical=
ly teachable. And it is true the implementations are not expected to suppor=
t such style well before it is enough widely adopted. (Consider performance=
 of template metaprogramming for example.) So (currently) it does not rock =
in practice. But that is a chicken and egg problem.<br><br>The boundary of =
static types and dynamic types are eliminating. Guaranteed translation-time=
 evaluation (`constexpr`) already make many differences away by allowing mo=
re constant-expressions keeping the syntax near to the traditional style. L=
ibraries like boost.hana are trying to eliminate the different look of comp=
utations between &quot;meta&quot; level and &quot;value&quot; level. Theore=
tically they are similar to gradual typing in purpose, but faked (by enforc=
ing phase requirements). Perhaps someday we can see some real mechanism of =
such proposed for the core language based on various field experience. Bett=
er embrace it :)<br></div></div></blockquote><div><br></div><div>Already em=
braced. There are some things I would like to see:</div><div><br></div><div=
>1. standardised c++ dependency manager (a-la npm, docker, cpan, pip)</div>=
<div>2. c++ implementations required to work in interpreter mode as well as=
 compiler mode.</div><div>3. standardisation of the emscripten c++ -&gt; ja=
vascript/wasm compiler.</div><div>4. standardisations of graphics, terminal=
, utf-8 string handling etc.</div><div><br></div><div>If we had that, the w=
orld would only need one language. We could achieve more.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><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"><div class=3D"gmail_quote=
"><div></div><div>But it could be that I am thinking myopically. I have exp=
erimented in the past with providing more &quot;script-like&quot; library o=
bjects to the odd project. Again, out of curiosity more than need.=C2=A0</d=
iv><div><br></div><div>You see what I&#39;m saying? Is this in reality a fu=
n personal project, or is there a tangible benefit to me if I find this in =
the std toolbox?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/c9664ef6-f769-4942-8e44-56761d091efc%=
40isocpp.org" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/c9664ef6-f769-4942-8e44-56761d091efc%40i=
socpp.org</a>.<br>
</blockquote></div></div>
</blockquote></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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f34f99a8-b633-4c0c-b472-1f20b64f71f2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f34f99a8-b633-=
4c0c-b472-1f20b64f71f2%40isocpp.org</a>.<br>
</blockquote></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/CALvx3ha7PWuqYR4vc%2BR92CM3CnmHf5oGki=
XsKoXVtvhXZvzKYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha7PWuqYR=
4vc%2BR92CM3CnmHf5oGkiXsKoXVtvhXZvzKYg%40mail.gmail.com</a>.<br />

--000000000000346fb205721d926e--

.

------=_Part_1155_1542295574.1534039230017
Content-Type: multipart/alternative;
 boundary="----=_Part_1156_874741824.1534039230017"

------=_Part_1156_874741824.1534039230017
Content-Type: text/plain; charset="UTF-8"

this idea is very funny.
i think one of tecnical topic.
this is lost mean the type's subeffect.
i seem look to the part of javascript.

i wanna goto remote region in austraria.hehe.

look forward.

--
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/5dbe9b5b-1706-49f4-8733-a2156572cfe5%40isocpp.org.

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

<div dir=3D"ltr"><div>this idea is very funny.</div><div>i think one of tec=
nical topic.</div><div>this is lost mean the type&#39;s subeffect.</div><di=
v>i seem look to the part of javascript.</div><div><br></div><div>i wanna g=
oto remote region in austraria.hehe.</div><div><br></div><div>look forward.=
</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/5dbe9b5b-1706-49f4-8733-a2156572cfe5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5dbe9b5b-1706-49f4-8733-a2156572cfe5=
%40isocpp.org</a>.<br />

------=_Part_1156_874741824.1534039230017--

------=_Part_1155_1542295574.1534039230017--

.