Topic: Request for interest: easier metaprogramming, bye
Author: =?UTF-8?Q?Germ=C3=A1n_Diago?= <germandiago@gmail.com>
Date: Wed, 21 Oct 2015 01:02:48 -0700 (PDT)
Raw View
------=_Part_5595_2022616759.1445414568473
Content-Type: multipart/alternative;
boundary="----=_Part_5596_1086545289.1445414568474"
------=_Part_5596_1086545289.1445414568474
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El mi=C3=A9rcoles, 21 de octubre de 2015, 14:38:07 (UTC+7), Germ=C3=A1n Dia=
go=20
escribi=C3=B3:
>
> Hello everyone,
>
> Every day I look at the D language metaprogramming facilities, I get more=
=20
> convinced that
> there are things missing in C++ that should make it in. Especially some=
=20
> kind of string
> mixin would be beneficial to get rid of some other preprocessor uses.
>
>
> I would like to know if there would be interest for the following=20
> proposals:
>
> In particular, I see that:
>
> 1. Not allowing string literals in templates is very painful: for a=20
> natural syntax we have
> to rely on creating a variable and passing a reference to the template=20
> argument and
> similar things. I saw several proposals, there will be some for C++17.
>
> There will be some for C++17? --- It was a question, not an affirmative=
=20
sentence.
=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_5596_1086545289.1445414568474
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>El mi=C3=A9rcoles, 21 de octubre de 2015, 14:38:07=
(UTC+7), Germ=C3=A1n Diago escribi=C3=B3:<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">Hello everyone,<br><br>Every day I look at th=
e D language metaprogramming facilities, I get more convinced that<br>there=
are things missing in C++ that should make it in. Especially some kind of =
string<br>mixin would be beneficial to get rid of some other preprocessor u=
ses.<br><br><br>I would like to know if there would be interest for the fol=
lowing proposals:<br><br>In particular, I see that:<br><br>1. Not allowing =
string literals in templates is very painful: for a natural syntax we have<=
br>to rely on creating a variable and passing a reference to the template a=
rgument and<br>similar things. I saw several proposals, there will be some =
for C++17.<br><br></div></blockquote><div>There will be some for C++17? ---=
It was a question, not an affirmative sentence.<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"><br></div></blockquo=
te></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_5596_1086545289.1445414568474--
------=_Part_5595_2022616759.1445414568473--
.
Author: Klemens Morgenstern <klemens.morgenstern@gmx.net>
Date: Wed, 21 Oct 2015 01:05:04 -0700 (PDT)
Raw View
------=_Part_144_355307309.1445414704130
Content-Type: multipart/alternative;
boundary="----=_Part_145_399727971.1445414704131"
------=_Part_145_399727971.1445414704131
Content-Type: text/plain; charset=UTF-8
I really like people coming up with ideas, but you should check if they fit
in without completly changing the language. C++ outh to be backwards
compatible. That is why languages like D are successful, they don't need to
keep all stuff the same, at least until major usage.
So if I am against your Ideas, well, it's not because I think the idea is
bad, but because it ought to work with C++. Please keep this in mind.
> 1. Not allowing string literals in templates is very painful: for a
> natural syntax we have
> to rely on creating a variable and passing a reference to the template
> argument and
> similar things. I saw several proposals, there will be some for C++17.
>
I don't know the excact reason for that, but it has something to do with
the way the linker handles the String. I'd guess this needs to be kept this
way for C-binary compatibility. If you want to propose something for the
standard you should also find the reason for the current implementation. It
may just be legacy, but it may also have a non-obvious reason.
An Idea I had, and you might work this out, is two allow strings for the
template user defined literal:
template<char...>
some_type operator""_s();
You could propose to either allow this syntax or to allow long chars with
that syntax. If you do the latter, you can just return a template-type and
pass either that type or a hash, as a template argument.
"my_string"_s
or
'my string'_s
There is also already a proposal for
that: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3599.html
>
>
2.- You cannot do what you can do with string mixin in C++ without macros,
> and we should get rid of macros, the sooner, the better, except for very
> niche uses.
> I have seen a few good uses of this technique.
>
We should not get rid of macros, as to remove them from the Standard. We
should discourage their use by providing alternatives.The problem is, that
I have no clue how this works in D. What you should do, if you want this
feature is to research the implementation in D and then propose a way this
could be done in C++. Write a proposal, I would be very interested.
>
> 3. Universal template parameter (like alias in D): a template parameter
> that can be either a type
> or a value:
>
Well if anything, you should propose to allow constexpr-constructible types
to be a template-parameter. I don't know the reason why doubles cannot be
template parameter, but I also guess it has one. You should find that out,
when writing a proposal.
> 4. Static if. (I saw constexpr_if in Pre-Kona). Seems the proposal does
> not allow for out of block
> evaluation, so the problem here would be that we cannot use it insted of
> #if/#ifdef. I think those
> cases should be covered with some non-preprocessor alternative.
>
There already was a proposal for
this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf
which was not accepted into C++ yet.
--
---
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_145_399727971.1445414704131
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I really like people coming up with ideas, but you should =
check if they fit in without completly changing the language. C++ outh to b=
e backwards compatible. That is why languages like D are successful, they d=
on't need to keep all stuff the same, at least until major usage.<br><b=
r>So if I am against your Ideas, well, it's not because I think the ide=
a is bad, but because it ought to work with C++. Please keep this in mind.<=
div><br><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>1=
.. Not allowing string literals in templates is very painful: for a natural =
syntax we have<br>to rely on creating a variable and passing a reference to=
the template argument and<br>similar things. I saw several proposals, ther=
e will be some for C++17.<br></div></blockquote><div><br></div><div>I don&#=
39;t know the excact reason for that, but it has something to do with the w=
ay the linker handles the String. I'd guess this needs to be kept this =
way for C-binary compatibility. If you want to propose something for the st=
andard you should also find the reason for the current implementation. It m=
ay just be legacy, but it may also have a non-obvious reason.</div><div><br=
></div><div>An Idea I had, and you might work this out, is two allow string=
s for the template user=C2=A0defined=C2=A0=C2=A0literal:</div><div><br></di=
v><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, =
187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">...></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>some_type </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">""</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">_s</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">();</span></font></div></code></di=
v><br>=C2=A0You could propose to either allow this syntax or to allow long =
chars with that syntax. If you do the latter, you can just return a templat=
e-type and pass either that type or a hash, as a template argument.</div><d=
iv><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">"my_string"=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_s</span><=
/font></div></code></div>or<br></div><div><div class=3D"prettyprint" style=
=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background=
-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><font color=3D"#660066"><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">'my string'</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">_s</span></font></div></code></div><div><br></d=
iv><div>There is also already a proposal for that:=C2=A0http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2013/n3599.html<br></div></div><div><br>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
=C2=A0<br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">2.- You cannot do what you can do with string mixin in C++ =
without macros,<br>and we should get rid of macros, the sooner, the better,=
except for very niche uses.<br>=C2=A0I have seen a few good uses of this t=
echnique. <br></div></blockquote><div><br></div><div>We should not get rid =
of macros, as to remove them from the Standard. We should discourage their =
use by providing alternatives.The problem is, that I have no clue how this =
works in D. What you should do, if you want this feature is to research the=
implementation in D and then propose a way this could be done in C++. Writ=
e a proposal, I would be very interested.</div><div><br></div><div>=C2=A0</=
div><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>3. Un=
iversal template parameter (like alias in D): a template parameter that can=
be either a type<br>or a value:</div></blockquote><div><br></div><div>Well=
if anything, you should propose to allow constexpr-constructible types to =
be a template-parameter. I don't know the reason why doubles cannot be =
template parameter, but I also guess it has one. You should find that out, =
when writing a proposal.<br></div><div><br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">4. Static if. (I saw c=
onstexpr_if in Pre-Kona). Seems the proposal does not allow for out of bloc=
k<br>evaluation, so the problem here would be that we cannot use it insted =
of #if/#ifdef. I think those<br>cases should be covered with some non-prepr=
ocessor alternative.<br></div></blockquote><div><br></div><div>There alread=
y was a proposal for this:=C2=A0http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2012/n3329.pdf which was not accepted into C++ yet.</div></div><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 />
------=_Part_145_399727971.1445414704131--
------=_Part_144_355307309.1445414704130--
.
Author: =?UTF-8?Q?Germ=C3=A1n_Diago?= <germandiago@gmail.com>
Date: Wed, 21 Oct 2015 02:12:59 -0700 (PDT)
Raw View
------=_Part_5572_1354105593.1445418779142
Content-Type: multipart/alternative;
boundary="----=_Part_5573_369689378.1445418779142"
------=_Part_5573_369689378.1445418779142
Content-Type: text/plain; charset=UTF-8
> 'my string'_s
>
> There is also already a proposal for that:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3599.html
>
As far as the proposal goes, I do not see this anywhere:
mytpe<"template_param"_s>. Would this be enabled by the proposal?
>
>
>
>
>>
>>
>
> We should not get rid of macros, as to remove them from the Standard. We
> should discourage their use by providing alternatives.The problem is, that
> I have no clue how this works in D. What you should do, if you want this
> feature is to research the implementation in D and then propose a way this
> could be done in C++. Write a proposal, I would be very interested.
>
> I did not claim to get rid of them. I just said as much as possible :) I
would also be interested in this itself, there are a few use cases for this
I guess.
>
>
>>
>> 3. Universal template parameter (like alias in D): a template parameter
>> that can be either a type
>> or a value:
>>
>
>
> Well if anything, you should propose to allow constexpr-constructible
> types to be a template-parameter. I don't know the reason why doubles
> cannot be template parameter, but I also guess it has one. You should find
> that out, when writing a proposal.
>
Did this make it in?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html
>
>
>
>> 4. Static if. (I saw constexpr_if in Pre-Kona). Seems the proposal does
>> not allow for out of block
>> evaluation, so the problem here would be that we cannot use it insted of
>> #if/#ifdef. I think those
>> cases should be covered with some non-preprocessor alternative.
>>
>
> There already was a proposal for this:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf which
> was not accepted into C++ yet.
>
Now we have constexpr_if in the works. Let us see... but it is more
restricted.
--
---
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_5573_369689378.1445418779142
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><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><div=
><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backg=
round-color:rgb(250,250,250)"><code><div><font color=3D"#660066"><span styl=
e=3D"color:#080">'my string'</span><span style=3D"color:#000">_s</s=
pan></font></div></code></div><div><br></div><div>There is also already a p=
roposal for that:=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2013/n3599.html" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3599.html\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNEljKrZPrdcCOBdLff6bZcsRw8KOQ';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open=
-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3599.html\46sa\75D\=
46sntz\0751\46usg\75AFQjCNEljKrZPrdcCOBdLff6bZcsRw8KOQ';return true;">h=
ttp://www.open-std.org/<wbr>jtc1/sc22/wg21/docs/papers/<wbr>2013/n3599.html=
</a></div></div></div></div></blockquote><div><br>As far as the proposal go=
es, I do not see this anywhere: mytpe<"template_param"_s>. =
Would this be enabled by the proposal?<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div><br></div></div=
><div><br>=C2=A0<br></div><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">=C2=A0<br></div></blockquote><br><div>We should not get rid of mac=
ros, as to remove them from the Standard. We should discourage their use by=
providing alternatives.The problem is, that I have no clue how this works =
in D. What you should do, if you want this feature is to research the imple=
mentation in D and then propose a way this could be done in C++. Write a pr=
oposal, I would be very interested.</div><div><br></div></div></div></block=
quote><div>I did not claim to get rid of them. I just said as much as possi=
ble :) I would also be interested in this itself, there are a few use cases=
for this I guess.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><div></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br>3. Universal template parameter=
(like alias in D): a template parameter that can be either a type<br>or a =
value:</div></blockquote><div><br></div></div></div></blockquote><div>=C2=
=A0</div><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=
><div></div><div>Well if anything, you should propose to allow constexpr-co=
nstructible types to be a template-parameter. I don't know the reason w=
hy doubles cannot be template parameter, but I also guess it has one. You s=
hould find that out, when writing a proposal.<br></div></div></div></blockq=
uote><div><br>Did this make it in? http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2012/n3413.html<br><br>=C2=A0<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><div></div><div><br></div><div>=
=C2=A0</div><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">4. Sta=
tic if. (I saw constexpr_if in Pre-Kona). Seems the proposal does not allow=
for out of block<br>evaluation, so the problem here would be that we canno=
t use it insted of #if/#ifdef. I think those<br>cases should be covered wit=
h some non-preprocessor alternative.<br></div></blockquote><div><br></div><=
div>There already was a proposal for this:=C2=A0<a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2012%2Fn=
3329.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNETAMiT6zfBNcyEXwfE0h3u0kFDNA=
9;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75=
http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2012%2=
Fn3329.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNETAMiT6zfBNcyEXwfE0h3u0kFDNA&=
#39;;return true;">http://www.open-std.org/<wbr>jtc1/sc22/wg21/docs/papers/=
<wbr>2012/n3329.pdf</a> which was not accepted into C++ yet.</div></div></d=
iv></blockquote><div><br>Now we have constexpr_if in the works. Let us see.=
... but it is more restricted. <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 />
------=_Part_5573_369689378.1445418779142--
------=_Part_5572_1354105593.1445418779142--
.
Author: Klemens Morgenstern <klemens.morgenstern@gmx.net>
Date: Wed, 21 Oct 2015 03:29:29 -0700 (PDT)
Raw View
------=_Part_239_562512726.1445423369338
Content-Type: multipart/alternative;
boundary="----=_Part_240_1778662142.1445423369338"
------=_Part_240_1778662142.1445423369338
Content-Type: text/plain; charset=UTF-8
>
> 'my string'_s
>>
>> There is also already a proposal for that:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3599.html
>>
>
> As far as the proposal goes, I do not see this anywhere:
> mytpe<"template_param"_s>. Would this be enabled by the proposal?
>
Not it wouldn't, and in fact you would still need to write a decltype
around it. That would be enabled.
But it implements the functionality and if that works reliably we could
propose to make the syntax easier. This would allow all sorts of amazing
stuff, easier static_strings and such.
It would look like this:
template<char...> struct static_string{};
template<char... Cs>
static_string<Cs...> operator""_s() {return {};}
template<typename T> struct X{};
X<decltype("MyStringTemplateParam"_s)> x;
If you wanted to use it directly, we'd need a std::static_string to do it.
But, if this proposal makes it into the standard, we would be one step
closer. So first this proposal, then a std::static_string and if that is
in, a shorthand-form for using static_string as a template-parameter.
Now we have constexpr_if in the works. Let us see... but it is more
> restricted.
>
Well, that's the way it goes. They are and should be careful with additions
to the standard. constexpr is the best example. It was quite restricted in
C++11 and since it worked quite well was relaxed in C++14. If you try to do
it the other way you're screwed - or a lot of people who's could you
destroyed are.
--
---
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_240_1778662142.1445423369338
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div><div style=3D"border:1px solid rgb(187=
,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><di=
v><font color=3D"#660066"><span style=3D"color:#080">'my string'</s=
pan><span style=3D"color:#000">_s</span></font></div></code></div><div><br>=
</div><div>There is also already a proposal for that:=C2=A0<a href=3D"http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3599.html" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpaper=
s%2F2013%2Fn3599.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEljKrZPrdcCOBdLff6=
bZcsRw8KOQ';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2013%2Fn3599.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEljKrZPrdcCOBdL=
ff6bZcsRw8KOQ';return true;">http://www.open-std.org/<wbr>jtc1/sc22/wg2=
1/docs/papers/<wbr>2013/n3599.html</a></div></div></div></div></blockquote>=
<div><br>As far as the proposal goes, I do not see this anywhere: mytpe<=
"template_param"_s>. Would this be enabled by the proposal?<br=
></div></blockquote><div><br></div><div>Not it wouldn't, and in fact yo=
u would still need to write a decltype around it. That would be enabled.=C2=
=A0</div><div>But it implements the functionality and if that works reliabl=
y we could propose to make the syntax easier. This would allow all sorts of=
amazing stuff, easier static_strings and such.</div><div><br></div><div>It=
would look like this:</div><div><br></div><div><br></div><div><div class=
=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">template</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">char</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">...></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> static_strin=
g</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Cs</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>static_string</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Cs</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">...></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"&quo=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_s</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{};}</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> X</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{};</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br>X</span><font color=3D"#008800">=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #080;" class=3D"styled-by-prettify">"MyStringTemplateParam"<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">_s</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)></span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span></font></div></code></di=
v><br>If you wanted to use it directly, we'd need a std::static_string =
to do it. But, if this proposal makes it into the standard, we would be one=
step closer. So first this proposal, then a std::static_string and if that=
is in, a shorthand-form for using static_string as a template-parameter.=
=C2=A0</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div>Now we have constexpr_if in the works. Let us see... but i=
t is more restricted. <br></div></blockquote><div><br></div><div>Well, that=
's the way it goes. They are and should be careful with additions to th=
e standard. constexpr is the best example. It was quite restricted in C++11=
and since it worked quite well was relaxed in C++14. If you try to do it t=
he other way you're screwed - or a lot of people who's could you de=
stroyed are.</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_240_1778662142.1445423369338--
------=_Part_239_562512726.1445423369338--
.
Author: snk_kid <korcan.hussein@googlemail.com>
Date: Fri, 23 Oct 2015 02:53:46 -0700 (PDT)
Raw View
------=_Part_1804_108632740.1445594026888
Content-Type: multipart/alternative;
boundary="----=_Part_1805_1040996842.1445594026895"
------=_Part_1805_1040996842.1445594026895
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, October 21, 2015 at 8:38:07 AM UTC+1, Germ=C3=A1n Diago wrote=
:
>
> Hello everyone,
>
> Every day I look at the D language metaprogramming facilities, I get more=
=20
> convinced that
> there are things missing in C++ that should make it in. Especially some=
=20
> kind of string
> mixin would be beneficial to get rid of some other preprocessor uses.
>
I would suggest looking into some other languages that have better=20
solutions to meta-programming than string mixins (e.g. Lisp, Nemerle,=20
MetaOcaml/SML, Template Haskell). Meta-programming based on strings is too=
=20
error prone, not type safe, minimal compiler support and just not well=20
maintainable. A better solution is a (type-safe) AST based macro system.=20
I think a better idea would be to continue expanding the capabilities=20
constexpr functions so that not only can they be used for pure compile-time=
=20
computations but also be used as type-safe AST macros that can=20
transform/generate code.
Adding another textual substitution macro system just seems like a step=20
back when constexpr is a good step forward.
I would recommend checking this=20
<https://github.com/rsdn/nemerle/wiki/Macros-tutorial> page about Nemerle's=
=20
AST macro system then imagine constexpr function like Nemerle's macros.
--=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_1805_1040996842.1445594026895
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 21, 2015 at 8:38:07 AM UTC+1, Germ=
=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello everyone,<br><br>Every day I look at the D language metaprog=
ramming facilities, I get more convinced that<br>there are things missing i=
n C++ that should make it in. Especially some kind of string<br>mixin would=
be beneficial to get rid of some other preprocessor uses.<br></div></block=
quote><div><br>I would suggest looking into some other languages that have =
better solutions to meta-programming than string mixins (e.g. Lisp, Nemerle=
, MetaOcaml/SML, Template Haskell). Meta-programming based on strings is to=
o error prone, not type safe, minimal compiler support and just not well ma=
intainable. A better solution is a (type-safe) AST based macro system. <br>=
<br>I think a better idea would be to continue expanding the capabilities c=
onstexpr functions so that not only can they be used for pure compile-time =
computations but also be used as type-safe AST macros that can transform/ge=
nerate code<code>.<span style=3D"font-family: arial,sans-serif;"><br></span=
></code><br><code><span style=3D"font-family: arial,sans-serif;"><code><spa=
n style=3D"font-family: arial,sans-serif;">Adding another textual substitut=
ion macro system just seems like a step back when constexpr is a good step =
forward.</span></code><br><br>I would recommend checking <a href=3D"https:/=
/github.com/rsdn/nemerle/wiki/Macros-tutorial">this</a> page about Nemerle&=
#39;s AST macro system then imagine constexpr function like Nemerle's m=
acros.</span><br><span style=3D"font-family: arial,sans-serif;"></span></co=
de></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_1805_1040996842.1445594026895--
------=_Part_1804_108632740.1445594026888--
.
Author: =?UTF-8?Q?Germ=C3=A1n_Diago?= <germandiago@gmail.com>
Date: Mon, 26 Oct 2015 02:34:07 -0700 (PDT)
Raw View
------=_Part_5412_1502086895.1445852047756
Content-Type: multipart/alternative;
boundary="----=_Part_5413_874543909.1445852047756"
------=_Part_5413_874543909.1445852047756
Content-Type: text/plain; charset=UTF-8
I would say that a full AST solution is very elaborated.
With mixins the compiler is going to be able to compile the code after
emitting anyway.
I think it works quite well and it would be easier to implement. I am not
sure how an AST solution would work.
I do know Lisp macros are great and Nemerle also looks cool, though I do
not know Nemerle well enough.
--
---
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_5413_874543909.1445852047756
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=C2=A0I would say that a full AST solution is very elabora=
ted.<br><br>With mixins the compiler is going to be able to compile the cod=
e after emitting anyway.<br><br>I think it works quite well and it would be=
easier to implement. I am not sure how an AST solution would work.<br>I do=
know Lisp macros are great and Nemerle also looks cool, though I do not kn=
ow Nemerle well enough.<br><iframe style=3D"padding: 0px; position: absolut=
e; top: 0px; left: 0px; width: 1050px; height: 188px; visibility: hidden;" =
frameborder=3D"0"></iframe></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_5413_874543909.1445852047756--
------=_Part_5412_1502086895.1445852047756--
.
Author: carterd@gmail.com
Date: Sat, 31 Oct 2015 05:02:44 -0700 (PDT)
Raw View
------=_Part_2453_2046980370.1446292964386
Content-Type: multipart/alternative;
boundary="----=_Part_2454_1675139909.1446292964386"
------=_Part_2454_1675139909.1446292964386
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I agree, the lack of literal operator template for strings was a huge=20
oversight, it's by far the most versatile because of its potential for=20
DSLs. The GCC extension is so simple and that would have been enough for my=
compile-time=20
heterogeneous map=20
<https://github.com/Qarterd/Honeycomb/blob/master/test/MtMap.cpp>. Usage=20
would be so much clearer:
keywordFunc(mtmap("name"_k =3D "bob", "age"_k =3D 10));
void keywordFunc(MtMap<int, decltype("age"_k),
string, decltype("name"_k),
optional<string>, decltype("alias"_k)> kwargs)
{
string name =3D kwargs["name"_k];
}=20
On Wednesday, October 21, 2015 at 12:38:07 AM UTC-7, Germ=C3=A1n Diago wrot=
e:
>
>
> 1. Not allowing string literals in templates is very painful: for a=20
> natural syntax we have
> to rely on creating a variable and passing a reference to the template=20
> argument and
> similar things. I saw several proposals, there will be some for C++17.
>
> For example:
>
> a. Named tuples.=20
>
> using Employee =3D tuple<string, "name", int, "age">;
>
> Employee e;
> e.name =3D ...;
> e.age =3D ...;
>
>
--=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_2454_1675139909.1446292964386
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree, the lack of literal operator template for strings=
was a huge oversight, it's by far the most versatile because of its po=
tential for DSLs. The GCC extension is so simple and that would have been e=
nough for my <a href=3D"https://github.com/Qarterd/Honeycomb/blob/master/te=
st/MtMap.cpp">compile-time heterogeneous map</a>. Usage would be so much cl=
earer:<br><br><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"subprettyprint"><code class=3D"prettyprint">keyword<span class=3D"pl-en=
">Func</span></code><code class=3D"prettyprint"><span class=3D"pl-en">(</sp=
an></code><code class=3D"prettyprint"><span class=3D"pl-en"><code class=3D"=
prettyprint"><span class=3D"pl-c1"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">mtmap</span></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span class=3D"pl-c1"><span style=3D"color: #08=
0;" class=3D"styled-by-prettify">"name"</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">_k</span></span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span class=3D"pl-s"><span class=3D"pl-pds"=
><span style=3D"color: #080;" class=3D"styled-by-prettify">"</span></s=
pan><span class=3D"pl-pds"><span style=3D"color: #080;" class=3D"styled-by-=
prettify">bob"</span></span></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">"age"</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">_k </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span class=3D"pl-c1"><span style=3D"color: #066;" class=3D"styled-by-=
prettify">10</span></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span></code>);</span></code><br><br><span class=3D"pl-k">void</=
span> keyword<span class=3D"pl-en">Func</span>(MtMap<int, decltype("=
;age"_k),<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
string<code class=3D"prettyprint">, decltype("name"_k),<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </code>optional<s=
tring>, <code class=3D"prettyprint"><code class=3D"prettyprint">decltype=
("alias"_k)</code></code>> kwargs)<br>{<br>=C2=A0=C2=A0=C2=A0 =
<code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">string name =3D </span></code><code class=3D"prettyprint">kwargs=
</code><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">[</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><code class=3D"prettyprint"><span class=3D"pl-c1"><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">"name"</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">_k</span></span></code>]</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">;</span></cod=
e><br>} <br></div></code></div><br><br><br>On Wednesday, October 21, 2015 a=
t 12:38:07 AM UTC-7, Germ=C3=A1n Diago wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><br>1. Not allowing string literals in temp=
lates is very painful: for a natural syntax we have<br>to rely on creating =
a variable and passing a reference to the template argument and<br>similar =
things. I saw several proposals, there will be some for C++17.<br><br>For e=
xample:<br><br>a. Named tuples. <br><br>using Employee =3D tuple<string,=
"name", int, "age">;<br><br>Employee e;<br><a href=
=3D"http://e.name" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fe.name\46sa\75D\46snt=
z\0751\46usg\75AFQjCNF7uV-ATrHM98Rr1IqI_VXfrs9OZg';return true;" onclic=
k=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fe.name\46s=
a\75D\46sntz\0751\46usg\75AFQjCNF7uV-ATrHM98Rr1IqI_VXfrs9OZg';return tr=
ue;">e.name</a> =3D ...;<br>e.age =3D ...;<br><br></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_2454_1675139909.1446292964386--
------=_Part_2453_2046980370.1446292964386--
.