Topic: Add std::begin and std::end for regular
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 20 Feb 2018 06:54:20 -0800 (PST)
Raw View
------=_Part_15642_45562061.1519138460850
Content-Type: multipart/alternative;
boundary="----=_Part_15643_1235136120.1519138460850"
------=_Part_15643_1235136120.1519138460850
Content-Type: text/plain; charset="UTF-8"
On Tuesday, February 20, 2018 at 3:35:28 AM UTC-5, frederik...@gmail.com
wrote:
>
> Currently, it is not possible to use extended for-loops with stuff like
> std::sregex_iterator, because there is no .begin()/.end() pair and no
> std::begin/std::end pair for std::sregex_iterator --
>
You don't use range-based for on *iterators*; you use them on *ranges*.
That's why it's called "range-based for".
What we ought to have is an `sregex_range` type.
--
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/807e4d20-ac2f-4075-92b5-6773540e77a3%40isocpp.org.
------=_Part_15643_1235136120.1519138460850
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 20, 2018 at 3:35:28 AM UTC-5, frederi=
k...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Currently, it is not possible to use extended for-loops with stuff=
like std::sregex_iterator, because there is no <font face=3D"courier new, =
monospace">.begin()</font>/<font face=3D"courier new, monospace">.end()</fo=
nt>=C2=A0pair and no <font face=3D"courier new, monospace">std::begin</font=
>/<font face=3D"courier new, monospace">std::end</font> pair for <font face=
=3D"courier new, monospace">std::sregex_iterator</font> --</div></blockquot=
e><div><br>You don't use range-based for on <i>iterators</i>; you use t=
hem on <i>ranges</i>. That's why it's called "range-based for&=
quot;.<br><br>What we ought to have is an `sregex_range` type.<br></div></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/807e4d20-ac2f-4075-92b5-6773540e77a3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/807e4d20-ac2f-4075-92b5-6773540e77a3=
%40isocpp.org</a>.<br />
------=_Part_15643_1235136120.1519138460850--
------=_Part_15642_45562061.1519138460850--
.
Author: frederik.hertzum@gmail.com
Date: Tue, 20 Feb 2018 13:52:54 -0800 (PST)
Raw View
------=_Part_914_1673442910.1519163574299
Content-Type: multipart/alternative;
boundary="----=_Part_915_1220559073.1519163574299"
------=_Part_915_1220559073.1519163574299
Content-Type: text/plain; charset="UTF-8"
Den tirsdag den 20. februar 2018 kl. 15.54.20 UTC+1 skrev Nicol Bolas:
>
> On Tuesday, February 20, 2018 at 3:35:28 AM UTC-5, frederik...@gmail.com
> wrote:
>>
>> Currently, it is not possible to use extended for-loops with stuff like
>> std::sregex_iterator, because there is no .begin()/.end() pair and no
>> std::begin/std::end pair for std::sregex_iterator --
>>
>
> You don't use range-based for on *iterators*; you use them on *ranges*.
> That's why it's called "range-based for".
>
> What we ought to have is an `sregex_range` type.
>
As long as I can use a "range-based" for loop, I'm fine. The needed changes
to the library is just very tiny if you accept that a std::sregex_iterator
is the beginning of the range and the end is whatever it is; no new types
required and things fits naturally in how the library and the language
already works.
If you want to add a `sregex_range` type, I'm sure that can be done better
with a generic range type for all iterator like types, rather than having a
specialized `sregex_range`.
Maybe sregex_iterator shouldn't have had _iterator in its name.
A `sregex_range` could be implemented quite easily as well though: just
combine a begin and an end, with a default on end the to a default
constructed end.
This should do the trick:
struct sregex_range : std::pair<std::sregex_iterator, std::sregex_iterator>
{
sregex_range(std::sregex_iterator begin, std::sregex_iterator end =
std::sregex_iterator()) : pair(begin, end) { }
std::sregex_iterator begin() { return first; }
std::sregex_iterator end() { return second; }
};
--
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/0c89bab9-4ffa-42a4-b407-44e62d16794b%40isocpp.org.
------=_Part_915_1220559073.1519163574299
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Den tirsdag den 20. februar 2018 kl. 15.54.20 UTC+1 skrev =
Nicol Bolas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Tuesday, February 20, 2018 at 3:35:28 AM UTC-5, <a>frederik...@gmail.com<=
/a> 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">Currentl=
y, it is not possible to use extended for-loops with stuff like std::sregex=
_iterator, because there is no <font face=3D"courier new, monospace">.begin=
()</font>/<font face=3D"courier new, monospace">.end()</font>=C2=A0pair and=
no <font face=3D"courier new, monospace">std::begin</font>/<font face=3D"c=
ourier new, monospace">std::end</font> pair for <font face=3D"courier new, =
monospace">std::sregex_iterator</font> --</div></blockquote><div><br>You do=
n't use range-based for on <i>iterators</i>; you use them on <i>ranges<=
/i>. That's why it's called "range-based for".<br><br>Wha=
t we ought to have is an `sregex_range` type.<br></div></div></blockquote><=
div><br>As long as I can use a "range-based" for loop, I'm fi=
ne. The needed changes to the library is just very tiny if you accept that =
a std::sregex_iterator is the beginning of the range and the end is whateve=
r it is; no new types required and things fits naturally in how the library=
and the language already works.<br><br>If you want to add a `sregex_range`=
type, I'm sure that can be done better with a generic range type for a=
ll iterator like types, rather than having a specialized `sregex_range`.<br=
><br>Maybe sregex_iterator shouldn't have had _iterator in its name.<br=
><br>A `sregex_range` could be implemented quite easily as well though: jus=
t combine a=C2=A0 begin and an end, with a default on end the to a default =
constructed end.<br><br><br>This should do the trick:<br><br>struct sregex_=
range : std::pair<std::sregex_iterator, std::sregex_iterator> {<br>=
=C2=A0=C2=A0=C2=A0 sregex_range(std::sregex_iterator begin, std::sregex_ite=
rator end =3D std::sregex_iterator()) : pair(begin, end) { }<br>=C2=A0=C2=
=A0=C2=A0 std::sregex_iterator begin() { return first; }<br>=C2=A0=C2=A0=C2=
=A0 std::sregex_iterator end() { return second; }<br>};<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" 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/0c89bab9-4ffa-42a4-b407-44e62d16794b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c89bab9-4ffa-42a4-b407-44e62d16794b=
%40isocpp.org</a>.<br />
------=_Part_915_1220559073.1519163574299--
------=_Part_914_1673442910.1519163574299--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Tue, 20 Feb 2018 14:35:11 -0800 (PST)
Raw View
------=_Part_16908_1356207015.1519166111983
Content-Type: multipart/alternative;
boundary="----=_Part_16909_1886244535.1519166111983"
------=_Part_16909_1886244535.1519166111983
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 20, 2018 at 12:35:28 AM UTC-8, frederik...@gmail.com=
=20
wrote:
>
> Currently, it is not possible to use extended for-loops with stuff like=
=20
> std::sregex_iterator, because there is no .begin()/.end() pair and no=20
> std::begin/std::end pair for std::sregex_iterator -- adding an overload=
=20
> for std::sregex_iterator to the std-namespace is trivial and doing so=20
> will allow using them in extended for-loops.
>
> I'm already doing this in production code and so far, have found no issue=
s=20
> with it.
>
Correct. I provided iterable iterators as part of the sample code for my=20
SCM Challenge puzzle at CppCon last year, IIRC.
I have a published proposal on the topic here:
http://quuxplusone.github.io/draft/iterable-regex-iterator.html
It was in the pre-ABQ 2017 mailing, if I recall correctly; but it was not=
=20
discussed in LEWG because I forgot about it.
I would be happy for anybody else to pick it up and run with it.
=E2=80=93Arthur
--=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/0978529c-c653-4e74-88de-127f0d797ef2%40isocpp.or=
g.
------=_Part_16909_1886244535.1519166111983
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 20, 2018 at 12:35:28 AM UTC-8, freder=
ik...@gmail.com 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">Currently, it is not possible to use extended for-loops with stuff=
like std::sregex_iterator, because there is no <font face=3D"courier new, =
monospace">.begin()</font>/<font face=3D"courier new, monospace">.end()</fo=
nt>=C2=A0pair and no <font face=3D"courier new, monospace">std::begin</font=
>/<font face=3D"courier new, monospace">std::end</font> pair for <font face=
=3D"courier new, monospace">std::sregex_iterator</font> -- adding an overlo=
ad for <font face=3D"courier new, monospace">std::sregex_iterator</font> to=
the <font face=3D"courier new, monospace">std</font>-namespace is trivial =
and doing so will allow using them in extended for-loops.<div><br></div><di=
v>I'm already doing this in production code and so far, have found no i=
ssues with it.</div></div></blockquote><div><br></div><div>Correct. I provi=
ded iterable iterators as part of the sample code for my SCM Challenge puzz=
le at CppCon last year, IIRC.</div><div><br></div><div>I have a published p=
roposal on the topic here:</div><div><a href=3D"http://quuxplusone.github.i=
o/draft/iterable-regex-iterator.html">http://quuxplusone.github.io/draft/it=
erable-regex-iterator.html</a><br></div><div>It was in the pre-ABQ 2017 mai=
ling, if I recall correctly; but it was not discussed in LEWG because I for=
got about it.</div><div>I would be happy for anybody else to pick it up and=
run with it.</div><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/0978529c-c653-4e74-88de-127f0d797ef2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0978529c-c653-4e74-88de-127f0d797ef2=
%40isocpp.org</a>.<br />
------=_Part_16909_1886244535.1519166111983--
------=_Part_16908_1356207015.1519166111983--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 20 Feb 2018 15:41:15 -0800 (PST)
Raw View
------=_Part_17196_1843841109.1519170075338
Content-Type: multipart/alternative;
boundary="----=_Part_17197_1802978061.1519170075339"
------=_Part_17197_1802978061.1519170075339
Content-Type: text/plain; charset="UTF-8"
The thing is, the regex library as a whole needs a full-fledged
modernization pass. Ranges should be a part of that (but proper RangeTS
versions, with iterator/sentinel pairs). The values of regex
matches/iterators deal a lot in `std::string` or `charT*`s; these are
obvious places where `string_view`s should be provided. And I'm sure other
people have other ideas.
--
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/08cd70e9-6fab-4d5e-91c9-0dd07183af6d%40isocpp.org.
------=_Part_17197_1802978061.1519170075339
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The thing is, the regex library as a whole needs a full-fl=
edged modernization pass. Ranges should be a part of that (but proper Range=
TS versions, with iterator/sentinel pairs). The values of regex matches/ite=
rators deal a lot in `std::string` or `charT*`s; these are obvious places w=
here `string_view`s should be provided. And I'm sure other people have =
other ideas.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/08cd70e9-6fab-4d5e-91c9-0dd07183af6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08cd70e9-6fab-4d5e-91c9-0dd07183af6d=
%40isocpp.org</a>.<br />
------=_Part_17197_1802978061.1519170075339--
------=_Part_17196_1843841109.1519170075338--
.
Author: frederik.hertzum@gmail.com
Date: Tue, 20 Feb 2018 23:08:21 -0800 (PST)
Raw View
------=_Part_17245_761471645.1519196902052
Content-Type: multipart/alternative;
boundary="----=_Part_17246_921581124.1519196902052"
------=_Part_17246_921581124.1519196902052
Content-Type: text/plain; charset="UTF-8"
Den onsdag den 21. februar 2018 kl. 00.41.15 UTC+1 skrev Nicol Bolas:
>
> The thing is, the regex library as a whole needs a full-fledged
> modernization pass. Ranges should be a part of that (but proper RangeTS
> versions, with iterator/sentinel pairs). The values of regex
> matches/iterators deal a lot in `std::string` or `charT*`s; these are
> obvious places where `string_view`s should be provided. And I'm sure other
> people have other ideas.
>
Using string_view instead of string is definitely welcome, but from my
point of view this is not the major problem; it's a non-functional
enhancement that only deals with efficiency (yieks! a c++ developer who
doesn't think efficiency is everything!). Also, it's fairly trivial to add
it.
Do you know of any other suggestions, besides Arthur's (who actually did
the work I was suggesting)?
--
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/56e49d2e-e39f-46d5-8bed-7696bf5f2f52%40isocpp.org.
------=_Part_17246_921581124.1519196902052
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Den onsdag den 21. februar 2018 kl. 00.41.15 UTC+1 skrev N=
icol Bolas:<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">Th=
e thing is, the regex library as a whole needs a full-fledged modernization=
pass. Ranges should be a part of that (but proper RangeTS versions, with i=
terator/sentinel pairs). The values of regex matches/iterators deal a lot i=
n `std::string` or `charT*`s; these are obvious places where `string_view`s=
should be provided. And I'm sure other people have other ideas.<br></d=
iv></blockquote><div><br>Using string_view instead of string is definitely =
welcome, but from my point of view this is not the major problem; it's =
a non-functional enhancement that only deals with efficiency (yieks! a c++ =
developer who doesn't think efficiency is everything!). Also, it's =
fairly trivial to add it.<br><br>Do you know of any other suggestions, besi=
des Arthur's (who actually did the work I was suggesting)?<br></div></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/56e49d2e-e39f-46d5-8bed-7696bf5f2f52%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/56e49d2e-e39f-46d5-8bed-7696bf5f2f52=
%40isocpp.org</a>.<br />
------=_Part_17246_921581124.1519196902052--
------=_Part_17245_761471645.1519196902052--
.