------=_Part_6_76936201.1435473850138
Content-Type: multipart/alternative;
 boundary="----=_Part_7_281574713.1435473850138"

------=_Part_7_281574713.1435473850138
Content-Type: text/plain; charset=UTF-8

Hi,

I am currently working on something I call "std::streams". It borrows ideas
from Linq (the collection extensions only) and Java 8 Streams but is
written STL-like and in line with the core C++ spirit (so no usual
line-by-line port). In the following I want to gauge the interest in such a
library.
I think generally, std algorithms can be quite cumbersome to use,
especially when you want to write queries over one or more data-structures
and not change/copy them. Recent standard changes, especially C++14 have
made lambdas quite a killer tool for porting LINQ to C++ (especially
lambdas with auto parameters).

While there are quite a number of attempts out there, they all lack in at
least two of the following:
1) Testcases & performance benchmarks (which leaves a bad impression)
2) Designed with standardization in mind (They often use boost, overload
operators, hack the language, are not zero abstraction, don't play well
with other STL concepts, etc.)
3) Are not generalized, making their usage quite inflexible
4) Use lazy evaluation (all I have seen so far require you to "collect" the
result into something very specific, like a vector, which is not awesome)

I have a prototype for "map" (x -> y), "zip" (x1, x2, x3,... ->
std::tuple<x1,x2,x3,...>) and "filter" (remove elements) so far. The main
challenges addressed here are:
1) Using iterator ranges. They work on anything that supports iteration
through std::begin/std::end (STL containers, initializer lists, etc.). They
return an iterator range. (If ranges are added to the standard they could
be upgraded to use them)
2) They are maximally generalized. For instance:
# "filter" allows you to modify the original container at only unfiltered
elements with "for(auto& x : filter(...))" and ofc through normal iterator
dereferencing. It keeps "bidirectionality" at most. So if you pass random
access, it will be demoted to bidirectional. If you pass something forward
iterable, filter will also just be forward iterable.
# "map" keeps the original iterator category, but ofc does not return
mutable references.
# "zip" keeps the original minimal iterator category of any passed
iterable. Allows you to modify specific elements of the source containers
in a for-loop etc. So you could do something like "for(auto& x:
filter(zip(...)))" and still modify the original vectors/containers the
"zip" was run on.
# All of them work with non-copyable, non-movable types, passed by const
reference, reference and move semantics. They are capable of owning
iterables (if passed via r-value).
3) "sort" can be similar, by still giving you mutable access to the backing
storage after sorting (in most practical cases).
4) They strieve zero-abstraction cost.
5) They have/will have an extensive test-suite testing each and every
single feature and code paths imaginable. As well as a benchmark suite to
verify zero abstraction cost.
6) They support static functions or pipelining, whichever you prefer. So
"map(filter().sort())" is entirely valid, if you like.

And of course, those are just the methods I currently have. I plan on
adding all the usual suspects ;).

Also I thought about tracking sorting via type information. This way
functions like min, max, find, etc. could take advantage of previously
sorted data (if it was sorted with the same algorithm that is now needed
too for ordering).

Please tell me what you think so far. I am willing to provide more info if
needed.

cheers
chris

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Hi,<div><br></div><div>I am currently working on something=
 I call "std::streams". It borrows ideas from Linq (the collection extensio=
ns only) and Java 8 Streams but is written STL-like and in line with the co=
re C++ spirit (so no usual line-by-line port). In the following I want to g=
auge the interest in such a library.</div><div>I think generally, std algor=
ithms can be quite cumbersome to use, especially when you want to write que=
ries over one or more data-structures and not change/copy them. Recent stan=
dard changes, especially C++14 have made lambdas quite a killer tool for po=
rting LINQ to C++ (especially lambdas with auto parameters).&nbsp;</div><di=
v><br></div><div>While there are quite a number of attempts out there, they=
 all lack in at least two of the following:</div><div>1) Testcases &amp; pe=
rformance benchmarks (which leaves a bad impression)</div><div>2) Designed =
with standardization in mind (They often use boost, overload operators, hac=
k the language, are not zero abstraction, don't play well with other STL co=
ncepts, etc.)</div><div>3) Are not generalized, making their usage quite in=
flexible</div><div>4) Use lazy evaluation (all I have seen so far require y=
ou to "collect" the result into something very specific, like a vector, whi=
ch is not awesome)</div><div><br></div><div>I have a prototype for "map" (x=
 -&gt; y), "zip" (x1, x2, x3,... -&gt; std::tuple&lt;x1,x2,x3,...&gt;) and =
"filter" (remove elements) so far. The main challenges addressed here are:<=
/div><div>1) Using iterator ranges. They work on anything that supports ite=
ration through std::begin/std::end (STL containers, initializer lists, etc.=
). They return an iterator range. (If ranges are added to the standard they=
 could be upgraded to use them)</div><div>2) They are maximally generalized=
.. For instance:</div><div># "filter" allows you to modify the original cont=
ainer at only unfiltered elements with "for(auto&amp; x : filter(...))" and=
 ofc through normal iterator dereferencing. It keeps "bidirectionality" at =
most. So if you pass random access, it will be demoted to bidirectional. If=
 you pass something forward iterable, filter will also just be forward iter=
able.</div><div># "map" keeps the original iterator category, but ofc does =
not return mutable references.&nbsp;</div><div># "zip"&nbsp;keeps the origi=
nal minimal iterator category of any passed iterable. Allows you to modify =
specific elements of the source containers in a for-loop etc. So you could =
do something like "for(auto&amp; x: filter(zip(...)))" and still modify the=
 original vectors/containers the "zip" was run on.</div><div># All of them =
work with non-copyable, non-movable types, passed by const reference, refer=
ence and move semantics. They are capable of owning iterables (if passed vi=
a r-value).&nbsp;</div><div>3) "sort" can be similar, by still giving you m=
utable access to the backing storage after sorting (in most practical cases=
).</div><div>4) They strieve zero-abstraction cost.</div><div>5) They have/=
will have an extensive test-suite testing each and every single feature and=
 code paths imaginable. As well as a benchmark suite to verify zero abstrac=
tion cost.</div><div>6) They support static functions or pipelining, whiche=
ver you prefer. So "map(filter().sort())" is entirely valid, if you like.</=
div><div><br></div><div>And of course, those are just the methods I current=
ly have. I plan on adding all the usual suspects ;).</div><div><br></div><d=
iv>Also I thought about tracking sorting via type information. This way fun=
ctions like min, max, find, etc. could take advantage of previously sorted =
data (if it was sorted with the same algorithm that is now needed too for o=
rdering).</div><div><br></div><div>Please tell me what you think so far. I =
am willing to provide more info if needed.</div><div><br></div><div>cheers<=
/div><div>chris</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7_281574713.1435473850138--
------=_Part_6_76936201.1435473850138--

.

Le 28/06/15 08:44, ChrisH a =C3=A9crit :
> Hi,
>
> I am currently working on something I call "std::streams". It borrows ide=
as
> from Linq (the collection extensions only) and Java 8 Streams but is
> written STL-like and in line with the core C++ spirit (so no usual
> line-by-line port). In the following I want to gauge the interest in such=
 a
> library.
> I think generally, std algorithms can be quite cumbersome to use,
> especially when you want to write queries over one or more data-structure=
s
> and not change/copy them. Recent standard changes, especially C++14 have
> made lambdas quite a killer tool for porting LINQ to C++ (especially
> lambdas with auto parameters).
>
> While there are quite a number of attempts out there, they all lack in at
> least two of the following:
> 1) Testcases & performance benchmarks (which leaves a bad impression)
> 2) Designed with standardization in mind (They often use boost, overload
> operators, hack the language, are not zero abstraction, don't play well
> with other STL concepts, etc.)
> 3) Are not generalized, making their usage quite inflexible
> 4) Use lazy evaluation (all I have seen so far require you to "collect" t=
he
> result into something very specific, like a vector, which is not awesome)
>
> I have a prototype for "map" (x -> y), "zip" (x1, x2, x3,... ->
> std::tuple<x1,x2,x3,...>) and "filter" (remove elements) so far. The main
> challenges addressed here are:
> 1) Using iterator ranges. They work on anything that supports iteration
> through std::begin/std::end (STL containers, initializer lists, etc.). Th=
ey
> return an iterator range. (If ranges are added to the standard they could
> be upgraded to use them)
> 2) They are maximally generalized. For instance:
> # "filter" allows you to modify the original container at only unfiltered
> elements with "for(auto& x : filter(...))" and ofc through normal iterato=
r
> dereferencing. It keeps "bidirectionality" at most. So if you pass random
> access, it will be demoted to bidirectional. If you pass something forwar=
d
> iterable, filter will also just be forward iterable.
> # "map" keeps the original iterator category, but ofc does not return
> mutable references.
> # "zip" keeps the original minimal iterator category of any passed
> iterable. Allows you to modify specific elements of the source containers
> in a for-loop etc. So you could do something like "for(auto& x:
> filter(zip(...)))" and still modify the original vectors/containers the
> "zip" was run on.
> # All of them work with non-copyable, non-movable types, passed by const
> reference, reference and move semantics. They are capable of owning
> iterables (if passed via r-value).
> 3) "sort" can be similar, by still giving you mutable access to the backi=
ng
> storage after sorting (in most practical cases).
> 4) They strieve zero-abstraction cost.
> 5) They have/will have an extensive test-suite testing each and every
> single feature and code paths imaginable. As well as a benchmark suite to
> verify zero abstraction cost.
> 6) They support static functions or pipelining, whichever you prefer. So
> "map(filter().sort())" is entirely valid, if you like.
>
> And of course, those are just the methods I currently have. I plan on
> adding all the usual suspects ;).
>
> Also I thought about tracking sorting via type information. This way
> functions like min, max, find, etc. could take advantage of previously
> sorted data (if it was sorted with the same algorithm that is now needed
> too for ordering).
>
> Please tell me what you think so far. I am willing to provide more info i=
f
> needed.
>
> cheers
> chris
>
Are you aware of the ongoing work on Range TS [1] [2]?

Vicente

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4382.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_249_1287275784.1435487591183
Content-Type: multipart/alternative;
 boundary="----=_Part_250_1493841810.1435487591183"

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

Thanks, I am now :D. I don't fully understand if that solves the issues I=
=20
wanted to solve but so far the range based algorithms look very promising.=
=20
Just hope they make it into the standard soon then.
Well, at least I learned a lot while implementing those 4 algorithms :D.=20

Also some examples:
https://github.com/ericniebler/range-v3/blob/master/example/calendar.cpp

On Sunday, 28 June 2015 12:03:58 UTC+2, Vicente J. Botet Escriba wrote:
>
> Le 28/06/15 08:44, ChrisH a =C3=A9crit :=20
> > Hi,=20
> >=20
> > I am currently working on something I call "std::streams". It borrows=
=20
> ideas=20
> > from Linq (the collection extensions only) and Java 8 Streams but is=20
> > written STL-like and in line with the core C++ spirit (so no usual=20
> > line-by-line port). In the following I want to gauge the interest in=20
> such a=20
> > library.=20
> > I think generally, std algorithms can be quite cumbersome to use,=20
> > especially when you want to write queries over one or more=20
> data-structures=20
> > and not change/copy them. Recent standard changes, especially C++14 hav=
e=20
> > made lambdas quite a killer tool for porting LINQ to C++ (especially=20
> > lambdas with auto parameters).=20
> >=20
> > While there are quite a number of attempts out there, they all lack in=
=20
> at=20
> > least two of the following:=20
> > 1) Testcases & performance benchmarks (which leaves a bad impression)=
=20
> > 2) Designed with standardization in mind (They often use boost, overloa=
d=20
> > operators, hack the language, are not zero abstraction, don't play well=
=20
> > with other STL concepts, etc.)=20
> > 3) Are not generalized, making their usage quite inflexible=20
> > 4) Use lazy evaluation (all I have seen so far require you to "collect"=
=20
> the=20
> > result into something very specific, like a vector, which is not=20
> awesome)=20
> >=20
> > I have a prototype for "map" (x -> y), "zip" (x1, x2, x3,... ->=20
> > std::tuple<x1,x2,x3,...>) and "filter" (remove elements) so far. The=20
> main=20
> > challenges addressed here are:=20
> > 1) Using iterator ranges. They work on anything that supports iteration=
=20
> > through std::begin/std::end (STL containers, initializer lists, etc.).=
=20
> They=20
> > return an iterator range. (If ranges are added to the standard they=20
> could=20
> > be upgraded to use them)=20
> > 2) They are maximally generalized. For instance:=20
> > # "filter" allows you to modify the original container at only=20
> unfiltered=20
> > elements with "for(auto& x : filter(...))" and ofc through normal=20
> iterator=20
> > dereferencing. It keeps "bidirectionality" at most. So if you pass=20
> random=20
> > access, it will be demoted to bidirectional. If you pass something=20
> forward=20
> > iterable, filter will also just be forward iterable.=20
> > # "map" keeps the original iterator category, but ofc does not return=
=20
> > mutable references.=20
> > # "zip" keeps the original minimal iterator category of any passed=20
> > iterable. Allows you to modify specific elements of the source=20
> containers=20
> > in a for-loop etc. So you could do something like "for(auto& x:=20
> > filter(zip(...)))" and still modify the original vectors/containers the=
=20
> > "zip" was run on.=20
> > # All of them work with non-copyable, non-movable types, passed by cons=
t=20
> > reference, reference and move semantics. They are capable of owning=20
> > iterables (if passed via r-value).=20
> > 3) "sort" can be similar, by still giving you mutable access to the=20
> backing=20
> > storage after sorting (in most practical cases).=20
> > 4) They strieve zero-abstraction cost.=20
> > 5) They have/will have an extensive test-suite testing each and every=
=20
> > single feature and code paths imaginable. As well as a benchmark suite=
=20
> to=20
> > verify zero abstraction cost.=20
> > 6) They support static functions or pipelining, whichever you prefer. S=
o=20
> > "map(filter().sort())" is entirely valid, if you like.=20
> >=20
> > And of course, those are just the methods I currently have. I plan on=
=20
> > adding all the usual suspects ;).=20
> >=20
> > Also I thought about tracking sorting via type information. This way=20
> > functions like min, max, find, etc. could take advantage of previously=
=20
> > sorted data (if it was sorted with the same algorithm that is now neede=
d=20
> > too for ordering).=20
> >=20
> > Please tell me what you think so far. I am willing to provide more info=
=20
> if=20
> > needed.=20
> >=20
> > cheers=20
> > chris=20
> >=20
> Are you aware of the ongoing work on Range TS [1] [2]?=20
>
> Vicente=20
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4382.pdf=20
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html=20
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Thanks, I am now :D. I don't fully understand if that solv=
es the issues I wanted to solve but so far the range based algorithms look =
very promising. Just hope they make it into the standard soon then.<div>Wel=
l, at least I learned a lot while implementing those 4 algorithms :D.&nbsp;=
<br></div><div><br></div><div>Also some examples:</div><div>https://github.=
com/ericniebler/range-v3/blob/master/example/calendar.cpp</div><div><div><b=
r>On Sunday, 28 June 2015 12:03:58 UTC+2, Vicente J. Botet Escriba  wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">Le 28/06/15 08:44, ChrisH a =C3=
=A9crit :
<br>&gt; Hi,
<br>&gt;
<br>&gt; I am currently working on something I call "std::streams". It borr=
ows ideas
<br>&gt; from Linq (the collection extensions only) and Java 8 Streams but =
is
<br>&gt; written STL-like and in line with the core C++ spirit (so no usual
<br>&gt; line-by-line port). In the following I want to gauge the interest =
in such a
<br>&gt; library.
<br>&gt; I think generally, std algorithms can be quite cumbersome to use,
<br>&gt; especially when you want to write queries over one or more data-st=
ructures
<br>&gt; and not change/copy them. Recent standard changes, especially C++1=
4 have
<br>&gt; made lambdas quite a killer tool for porting LINQ to C++ (especial=
ly
<br>&gt; lambdas with auto parameters).
<br>&gt;
<br>&gt; While there are quite a number of attempts out there, they all lac=
k in at
<br>&gt; least two of the following:
<br>&gt; 1) Testcases &amp; performance benchmarks (which leaves a bad impr=
ession)
<br>&gt; 2) Designed with standardization in mind (They often use boost, ov=
erload
<br>&gt; operators, hack the language, are not zero abstraction, don't play=
 well
<br>&gt; with other STL concepts, etc.)
<br>&gt; 3) Are not generalized, making their usage quite inflexible
<br>&gt; 4) Use lazy evaluation (all I have seen so far require you to "col=
lect" the
<br>&gt; result into something very specific, like a vector, which is not a=
wesome)
<br>&gt;
<br>&gt; I have a prototype for "map" (x -&gt; y), "zip" (x1, x2, x3,... -&=
gt;
<br>&gt; std::tuple&lt;x1,x2,x3,...&gt;) and "filter" (remove elements) so =
far. The main
<br>&gt; challenges addressed here are:
<br>&gt; 1) Using iterator ranges. They work on anything that supports iter=
ation
<br>&gt; through std::begin/std::end (STL containers, initializer lists, et=
c.). They
<br>&gt; return an iterator range. (If ranges are added to the standard the=
y could
<br>&gt; be upgraded to use them)
<br>&gt; 2) They are maximally generalized. For instance:
<br>&gt; # "filter" allows you to modify the original container at only unf=
iltered
<br>&gt; elements with "for(auto&amp; x : filter(...))" and ofc through nor=
mal iterator
<br>&gt; dereferencing. It keeps "bidirectionality" at most. So if you pass=
 random
<br>&gt; access, it will be demoted to bidirectional. If you pass something=
 forward
<br>&gt; iterable, filter will also just be forward iterable.
<br>&gt; # "map" keeps the original iterator category, but ofc does not ret=
urn
<br>&gt; mutable references.
<br>&gt; # "zip" keeps the original minimal iterator category of any passed
<br>&gt; iterable. Allows you to modify specific elements of the source con=
tainers
<br>&gt; in a for-loop etc. So you could do something like "for(auto&amp; x=
:
<br>&gt; filter(zip(...)))" and still modify the original vectors/container=
s the
<br>&gt; "zip" was run on.
<br>&gt; # All of them work with non-copyable, non-movable types, passed by=
 const
<br>&gt; reference, reference and move semantics. They are capable of ownin=
g
<br>&gt; iterables (if passed via r-value).
<br>&gt; 3) "sort" can be similar, by still giving you mutable access to th=
e backing
<br>&gt; storage after sorting (in most practical cases).
<br>&gt; 4) They strieve zero-abstraction cost.
<br>&gt; 5) They have/will have an extensive test-suite testing each and ev=
ery
<br>&gt; single feature and code paths imaginable. As well as a benchmark s=
uite to
<br>&gt; verify zero abstraction cost.
<br>&gt; 6) They support static functions or pipelining, whichever you pref=
er. So
<br>&gt; "map(filter().sort())" is entirely valid, if you like.
<br>&gt;
<br>&gt; And of course, those are just the methods I currently have. I plan=
 on
<br>&gt; adding all the usual suspects ;).
<br>&gt;
<br>&gt; Also I thought about tracking sorting via type information. This w=
ay
<br>&gt; functions like min, max, find, etc. could take advantage of previo=
usly
<br>&gt; sorted data (if it was sorted with the same algorithm that is now =
needed
<br>&gt; too for ordering).
<br>&gt;
<br>&gt; Please tell me what you think so far. I am willing to provide more=
 info if
<br>&gt; needed.
<br>&gt;
<br>&gt; cheers
<br>&gt; chris
<br>&gt;
<br>Are you aware of the ongoing work on Range TS [1] [2]?
<br>
<br>Vicente
<br>
<br>[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/=
n4382.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2015%2Fn4382.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCN=
FbLvCzNn4jMYgmK8cDXyyFM6N6mQ';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fpapers%2F2015%2Fn4382.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFbLvCz=
Nn4jMYgmK8cDXyyFM6N6mQ';return true;">http://www.open-std.org/jtc1/<wbr>sc2=
2/wg21/docs/papers/2015/<wbr>n4382.pdf</a>
<br>[2] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/=
n4128.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4128.html\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHbrU8Hr_F_Sdl01PfSgDGVC-1kRQ';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2014%2Fn4128.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHbr=
U8Hr_F_Sdl01PfSgDGVC-1kRQ';return true;">http://www.open-std.org/jtc1/<wbr>=
sc22/wg21/docs/papers/2014/<wbr>n4128.html</a>
<br>
<br></blockquote></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_250_1493841810.1435487591183--
------=_Part_249_1287275784.1435487591183--

.