Topic: extention methods or UFCS
Author: walter1234 <walter2bz@gmail.com>
Date: Sat, 4 Oct 2014 20:32:31 -0700 (PDT)
Raw View
------=_Part_5084_462084247.1412479951275
Content-Type: text/plain; charset=UTF-8
How much support or interest is there in the C++ community for either of
these at the minute.
Has anyone tried to extend any C++ compiler to add these?
If someone added them in a nonstandard fork, what would be the chances of
getting them accepted in a mainstream compiler (behind a toggle).
it's absence my biggest gripe in the language (asymmetry between methods &
functions, & how it interacts with header files);
Of everything i've seen, my favourite solution is D's UFCS idea. Rusts'
traits/impls are ok, but they have their own annoyance (I prefer how open
free-functions are)
its' about ease of refactoring between methods/free-function code, and
readability (having the convenient chaining/aproximate-infix syntax always
available)
extention methods wouldn't be expected in vtables, just for compile-time
dispatch.
--
---
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_5084_462084247.1412479951275
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div>How much support or interest is there in the C++ =
community for either of these at the minute.</div><div><br></div><div>Has a=
nyone tried to extend any C++ compiler to add these?</div><div><br></div><d=
iv>If someone added them in a nonstandard fork, what would be the chances o=
f getting them accepted in a mainstream compiler (behind a toggle).</div><d=
iv><br></div><div><br></div><div>it's absence my biggest gripe in the langu=
age (asymmetry between methods & functions, & how it interacts with=
header files);</div><div><br></div><div>Of everything i've seen, my favour=
ite solution is D's UFCS idea. Rusts' traits/impls are ok, but they have th=
eir own annoyance (I prefer how open free-functions are)</div><div><br></di=
v><div>its' about ease of refactoring between methods/free-function code, a=
nd readability (having the convenient chaining/aproximate-infix syntax alwa=
ys available)</div><div><br></div><div>extention methods wouldn't be expect=
ed in vtables, just for compile-time dispatch.</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" 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_5084_462084247.1412479951275--
.
Author: masse.nicolas@gmail.com
Date: Mon, 6 Oct 2014 04:05:11 -0700 (PDT)
Raw View
------=_Part_10326_1237235647.1412593511969
Content-Type: text/plain; charset=UTF-8
Things like extensions methods have already been discussed here. see Have
"extension methods" been proposed for C++1y? (or any previous standard)
<https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/17tP4GJbYaI>
;-)
For D's UFCS, I like the idea, but I think there will some difficulties
like passing the 1st argument by a reference, by copying the value or using
a pointer. Also there could be a question about the fact that the 1st
parameter could or should be constant (remember, this in c++ is declared as
a constant pointer).
Anyway, as I said i like the idea.
On Sunday, October 5, 2014 5:32:31 AM UTC+2, walter1234 wrote:
>
>
> How much support or interest is there in the C++ community for either of
> these at the minute.
>
> Has anyone tried to extend any C++ compiler to add these?
>
> If someone added them in a nonstandard fork, what would be the chances of
> getting them accepted in a mainstream compiler (behind a toggle).
>
>
> it's absence my biggest gripe in the language (asymmetry between methods &
> functions, & how it interacts with header files);
>
> Of everything i've seen, my favourite solution is D's UFCS idea. Rusts'
> traits/impls are ok, but they have their own annoyance (I prefer how open
> free-functions are)
>
> its' about ease of refactoring between methods/free-function code, and
> readability (having the convenient chaining/aproximate-infix syntax always
> available)
>
> extention methods wouldn't be expected in vtables, just for compile-time
> dispatch.
>
--
---
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_10326_1237235647.1412593511969
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Things like extensions methods have already been discussed=
here. see <a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgro=
ups#!topic/std-proposals/17tP4GJbYaI">Have "extension methods" been propose=
d for C++1y? (or any previous standard)</a> ;-)<br>For D's UFCS, I like th=
e idea, but I think there will some difficulties like passing the 1st argum=
ent by a reference, by copying the value or using a pointer. Also there cou=
ld be a question about the fact that the 1st parameter could or should be c=
onstant (remember, this in c++ is declared as a constant pointer).<br>Anywa=
y, as I said i like the idea.<br><br><br>On Sunday, October 5, 2014 5:32:31=
AM UTC+2, walter1234 wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><br><div>How much support or interest is there in the C++ co=
mmunity for either of these at the minute.</div><div><br></div><div>Has any=
one tried to extend any C++ compiler to add these?</div><div><br></div><div=
>If someone added them in a nonstandard fork, what would be the chances of =
getting them accepted in a mainstream compiler (behind a toggle).</div><div=
><br></div><div><br></div><div>it's absence my biggest gripe in the languag=
e (asymmetry between methods & functions, & how it interacts with h=
eader files);</div><div><br></div><div>Of everything i've seen, my favourit=
e solution is D's UFCS idea. Rusts' traits/impls are ok, but they have thei=
r own annoyance (I prefer how open free-functions are)</div><div><br></div>=
<div>its' about ease of refactoring between methods/free-function code, and=
readability (having the convenient chaining/aproximate-infix syntax always=
available)</div><div><br></div><div>extention methods wouldn't be expected=
in vtables, just for compile-time dispatch.</div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
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_10326_1237235647.1412593511969--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Mon, 6 Oct 2014 13:09:47 +0200
Raw View
--089e0158a9a64ff8c60504bf21dd
Content-Type: text/plain; charset=UTF-8
+1
--
J. Daniel
On Mon, Oct 6, 2014 at 1:05 PM, <masse.nicolas@gmail.com> wrote:
> Things like extensions methods have already been discussed here. see Have
> "extension methods" been proposed for C++1y? (or any previous standard)
> <https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/17tP4GJbYaI>
> ;-)
> For D's UFCS, I like the idea, but I think there will some difficulties
> like passing the 1st argument by a reference, by copying the value or using
> a pointer. Also there could be a question about the fact that the 1st
> parameter could or should be constant (remember, this in c++ is declared as
> a constant pointer).
> Anyway, as I said i like the idea.
>
>
>
> On Sunday, October 5, 2014 5:32:31 AM UTC+2, walter1234 wrote:
>>
>>
>> How much support or interest is there in the C++ community for either of
>> these at the minute.
>>
>> Has anyone tried to extend any C++ compiler to add these?
>>
>> If someone added them in a nonstandard fork, what would be the chances of
>> getting them accepted in a mainstream compiler (behind a toggle).
>>
>>
>> it's absence my biggest gripe in the language (asymmetry between methods
>> & functions, & how it interacts with header files);
>>
>> Of everything i've seen, my favourite solution is D's UFCS idea. Rusts'
>> traits/impls are ok, but they have their own annoyance (I prefer how open
>> free-functions are)
>>
>> its' about ease of refactoring between methods/free-function code, and
>> readability (having the convenient chaining/aproximate-infix syntax always
>> available)
>>
>> extention methods wouldn't be expected in vtables, just for compile-time
>> dispatch.
>>
> --
>
> ---
> 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/.
>
--
---
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/.
--089e0158a9a64ff8c60504bf21dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">+1<div class=3D"gmail_extra">--</div><div class=3D"gmail_e=
xtra">=C2=A0 J. Daniel<br clear=3D"all"><div><div dir=3D"ltr"><br></div></d=
iv><div class=3D"gmail_quote">On Mon, Oct 6, 2014 at 1:05 PM, <span dir=3D=
"ltr"><<a href=3D"mailto:masse.nicolas@gmail.com" target=3D"_blank">mass=
e.nicolas@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Things like extensions methods have already been discusse=
d here. see <a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgr=
oups#!topic/std-proposals/17tP4GJbYaI" target=3D"_blank">Have "extensi=
on methods" been proposed for C++1y? (or any previous standard)</a> ;-=
)<br>For D's UFCS, I like the idea, but I think there will some diffic=
ulties like passing the 1st argument by a reference, by copying the value o=
r using a pointer. Also there could be a question about the fact that the 1=
st parameter could or should be constant (remember, this in c++ is declared=
as a constant pointer).<br>Anyway, as I said i like the idea.<div><div><br=
><br><br>On Sunday, October 5, 2014 5:32:31 AM UTC+2, walter1234 wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>How much supp=
ort or interest is there in the C++ community for either of these at the mi=
nute.</div><div><br></div><div>Has anyone tried to extend any C++ compiler =
to add these?</div><div><br></div><div>If someone added them in a nonstanda=
rd fork, what would be the chances of getting them accepted in a mainstream=
compiler (behind a toggle).</div><div><br></div><div><br></div><div>it'=
;s absence my biggest gripe in the language (asymmetry between methods &=
; functions, & how it interacts with header files);</div><div><br></div=
><div>Of everything i've seen, my favourite solution is D's UFCS id=
ea. Rusts' traits/impls are ok, but they have their own annoyance (I pr=
efer how open free-functions are)</div><div><br></div><div>its' about e=
ase of refactoring between methods/free-function code, and readability (hav=
ing the convenient chaining/aproximate-infix syntax always available)</div>=
<div><br></div><div>extention methods wouldn't be expected in vtables, =
just for compile-time dispatch.</div></div></blockquote></div></div></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" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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" 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 />
--089e0158a9a64ff8c60504bf21dd--
.
Author: walter lynsdale <walter2bz@gmail.com>
Date: Wed, 8 Oct 2014 23:35:19 +0100
Raw View
--f46d04374a0d47ffef0504f0ee24
Content-Type: text/plain; charset=UTF-8
Could anyone who knows clang comment which would be easier to do
[1] just allow declaring void Foo::bar(...args..){...}
[2] void bar(Foo* this, ...args...) // explicit 'this' is an extention
method
[3] some other keyword. like
extend_class Foo {
void bar(...args...);
}
[4] just implement something close to D ufcs. `a.bar(...args...)` first
binds to class methods, then looks for bar(&a,...args...), then
bar(a,...args...)? a->bar(...args) tries class methods, then
bar(a,..args..), then bar(*a,...args...)
r.e. access rights, I think extention methods should have the same
visibility/acess as free functions.
Which would be most likely to gain widespread acceptance.
which has the least chance of hazardous interactions
On Mon, Oct 6, 2014 at 12:09 PM, J. Daniel Garcia <josedaniel.garcia@uc3m.es
> wrote:
> +1
> --
> J. Daniel
>
> On Mon, Oct 6, 2014 at 1:05 PM, <masse.nicolas@gmail.com> wrote:
>
>> Things like extensions methods have already been discussed here. see Have
>> "extension methods" been proposed for C++1y? (or any previous standard)
>> <https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/17tP4GJbYaI>
>> ;-)
>> For D's UFCS, I like the idea, but I think there will some difficulties
>> like passing the 1st argument by a reference, by copying the value or using
>> a pointer. Also there could be a question about the fact that the 1st
>> parameter could or should be constant (remember, this in c++ is declared as
>> a constant pointer).
>> Anyway, as I said i like the idea.
>>
>>
>>
>> On Sunday, October 5, 2014 5:32:31 AM UTC+2, walter1234 wrote:
>>>
>>>
>>> How much support or interest is there in the C++ community for either of
>>> these at the minute.
>>>
>>> Has anyone tried to extend any C++ compiler to add these?
>>>
>>> If someone added them in a nonstandard fork, what would be the chances
>>> of getting them accepted in a mainstream compiler (behind a toggle).
>>>
>>>
>>> it's absence my biggest gripe in the language (asymmetry between methods
>>> & functions, & how it interacts with header files);
>>>
>>> Of everything i've seen, my favourite solution is D's UFCS idea. Rusts'
>>> traits/impls are ok, but they have their own annoyance (I prefer how open
>>> free-functions are)
>>>
>>> its' about ease of refactoring between methods/free-function code, and
>>> readability (having the convenient chaining/aproximate-infix syntax always
>>> available)
>>>
>>> extention methods wouldn't be expected in vtables, just for compile-time
>>> dispatch.
>>>
>> --
>>
>> ---
>> 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/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/fa42g-XAeD4/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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/.
--f46d04374a0d47ffef0504f0ee24
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Could anyone who knows clang comment which would be easier=
to do<div><br></div><div>[1] just allow declaring =C2=A0void Foo::bar(...a=
rgs..){...}</div><div>[2] =C2=A0 void bar(Foo* this, ...args...) =C2=A0 =C2=
=A0// explicit 'this' is an extention method</div><div>[3] some oth=
er keyword. like</div><div>extend_class =C2=A0Foo {</div><div>=C2=A0 =C2=A0=
void bar(...args...);</div><div>}=C2=A0</div><div>[4] just implement somet=
hing close to D ufcs. =C2=A0 `a.bar(...args...)` =C2=A0first binds to class=
methods, then looks for bar(&a,...args...), then bar(a,...args...)? =
=C2=A0 =C2=A0a->bar(...args) tries class methods, then bar(a,..args..), =
then bar(*a,...args...)</div><div><br></div><div>r.e. access rights, I thin=
k extention methods should have the same visibility/acess as free functions=
..</div><div><br></div><div>Which would be most likely to gain widespread ac=
ceptance.</div><div>which has the least chance of hazardous interactions</d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, =
Oct 6, 2014 at 12:09 PM, J. Daniel Garcia <span dir=3D"ltr"><<a href=3D"=
mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.=
es</a>></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"=
>+1<div class=3D"gmail_extra">--</div><div class=3D"gmail_extra">=C2=A0 J. =
Daniel<br clear=3D"all"><div><div dir=3D"ltr"><br></div></div><div class=3D=
"gmail_quote"><span class=3D"">On Mon, Oct 6, 2014 at 1:05 PM, <span dir=
=3D"ltr"><<a href=3D"mailto:masse.nicolas@gmail.com" target=3D"_blank">m=
asse.nicolas@gmail.com</a>></span> wrote:<br></span><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><span class=3D""><div dir=3D"ltr">Things like extensions methods=
have already been discussed here. see <a href=3D"https://groups.google.com=
/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/17tP4GJbYaI" target=3D=
"_blank">Have "extension methods" been proposed for C++1y? (or an=
y previous standard)</a> ;-)<br>For D's UFCS, I like the idea, but I t=
hink there will some difficulties like passing the 1st argument by a refere=
nce, by copying the value or using a pointer. Also there could be a questio=
n about the fact that the 1st parameter could or should be constant (rememb=
er, this in c++ is declared as a constant pointer).<br>Anyway, as I said i =
like the idea.<div><div><br><br><br>On Sunday, October 5, 2014 5:32:31 AM U=
TC+2, walter1234 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"><br><div>How much support or interest is there in the C++ community fo=
r either of these at the minute.</div><div><br></div><div>Has anyone tried =
to extend any C++ compiler to add these?</div><div><br></div><div>If someon=
e added them in a nonstandard fork, what would be the chances of getting th=
em accepted in a mainstream compiler (behind a toggle).</div><div><br></div=
><div><br></div><div>it's absence my biggest gripe in the language (asy=
mmetry between methods & functions, & how it interacts with header =
files);</div><div><br></div><div>Of everything i've seen, my favourite =
solution is D's UFCS idea. Rusts' traits/impls are ok, but they hav=
e their own annoyance (I prefer how open free-functions are)</div><div><br>=
</div><div>its' about ease of refactoring between methods/free-function=
code, and readability (having the convenient chaining/aproximate-infix syn=
tax always available)</div><div><br></div><div>extention methods wouldn'=
;t be expected in vtables, just for compile-time dispatch.</div></div></blo=
ckquote></div></div></div></span><div><div><span class=3D"HOEnZb"><font col=
or=3D"#888888">
<p></p>
-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.</font></span><span class=
=3D""><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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div></div><div class=3D"HOEnZb"=
><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/fa42g-XAeD4/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/fa42g-XAeD4=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <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 />
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 />
--f46d04374a0d47ffef0504f0ee24--
.