On 12/04/2015 11:01 PM, Matt Calabrese wrote:
> Does this affect when the noexcept specification of a function is
> evaluated in a way that can break existing code, especially if the
> noexcept specification deals with dependent types?

The point-of-instantiation of noexcept specifiers is not touched
by the paper.

> Does this implicitly change anything regarding SFINAE,

The paper is changing the type system, so the effects are detectable
with SFINAE.

>   is that
> intentional with rationale, or is this incidental? From examining the
> proposed changes, my understanding is that nothing here explicitly
> changes with respect to SFINAE, so expressions appearing in the
> noexcept specification would cause a hard error if overload
> resolution would yield an instantiation of a function template
> declaration that has a noexcept specifier with an expression that
> would otherwise have caused SFINAE had that expression appeared in
> the return type/parameter list/template parameter list. Is this a
> correct assessment? If so, this is probably the safest route forward
> to not risk subtle breakages and I am in favor of it, but I'm not
> 100% sure that this is the effect of the proposal, so I'd like some
> clarification.

The instantiation of the stuff inside the noexcept specifier is not
changed by the paper.

> There is also an example case that I'm curious about:

> template <class T>
> struct foo {
>   typename T::type bar();
>   void baz() noexcept(noexcept(typename T::type{}));
> };

> In current C++, this code would produce a compile-time error simply
> by instantiating foo<int> without using "bar". However, this would
> /not/ produce a hard error for "baz" if foo<int> were instantiated.

noexcept-specifications are instantiated "when needed", similar
to default arguments expressions.  I would expect that they
continue to be delayed-instantiated in cases like the one shown
above.

Jens

--

---
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_366_1372494366.1461198768110
Content-Type: multipart/alternative;
 boundary="----=_Part_367_923657735.1461198768110"

------=_Part_367_923657735.1461198768110
Content-Type: text/plain; charset=UTF-8

But isn't that inconsistent with C++11 expression sfinae?
Substitution failure occurs in "all expressions used in the function type"
quoting cppreference.com on SFINAE.
With p0012 accepted into C++17, the noexcept specifier is a part of the
function type, so this quote should be changed to "all expressions used in
the function type except noexcept (I had to :)) specifier" ?
Is it only because of those subtle breakages mentioned ?
Turning a hard error into substitution failure only "breaks" code that
didn't compile in C++14 which is a NOT a breaking change in my book
(exactly like C++11 expression SFINAE and p238r0 return type deduction
SFINAE) so actually, what subtle breakages?
I was actually surprised noexcept-specifier isn't a SFINAE context even in
C++11/14 (when my compiler shouted at me), but maybe that's just me.

On Saturday, December 5, 2015 at 12:01:26 AM UTC+2, Matt Calabrese wrote:
>
> I'm very much in favor of making noexcept-ness a part of the function
> type, but subtle details of this paper are not fully clear to me when
> looking at the specified changes and so I'm unable to say whether I'd be in
> favor of those details. In particular, it would be nice if this paper or
> the author explicitly addressed the following questions:
> Does this affect when the noexcept specification of a function is
> evaluated in a way that can break existing code, especially if the noexcept
> specification deals with dependent types?
> Does this implicitly change anything regarding SFINAE, is that intentional
> with rationale, or is this incidental? From examining the proposed changes,
> my understanding is that nothing here explicitly changes with respect to
> SFINAE, so expressions appearing in the noexcept specification would cause
> a hard error if overload resolution would yield an instantiation of a
> function template declaration that has a noexcept specifier with an
> expression that would otherwise have caused SFINAE had that expression
> appeared in the return type/parameter list/template parameter list. Is this
> a correct assessment? If so, this is probably the safest route forward to
> not risk subtle breakages and I am in favor of it, but I'm not 100% sure
> that this is the effect of the proposal, so I'd like some clarification.
>
> There is also an example case that I'm curious about:
>
> //////////
> template <class T>
> struct foo {
>   typename T::type bar();
>   void baz() noexcept(noexcept(typename T::type{}));
> };
> //////////
>
> In current C++, this code would produce a compile-time error simply by
> instantiating foo<int> without using "bar". However, this would *not*
> produce a hard error for "baz" if foo<int> were instantiated. Does the fact
> that the noexcept-ness is now a part of the function type implicitly change
> the above code such that instantiating foo<int> would be an error even if
> "baz" isn't invoked? My current understanding of the proposal is that this
> code would *not* change in the sense that "baz" would continue to not
> cause a hard error merely by instantiating foo<int>, since the full
> function type is not always determined at that time. If I'm wrong and the
> proposal would now make foo<int> have a hard error because of "baz", is it
> possible to make it such that this code wouldn't break?
>
> Thanks.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5bba1f89-66ee-4e0f-8d15-598f379abc93%40isocpp.org.

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

<div dir=3D"ltr">But isn&#39;t that inconsistent with C++11 expression sfin=
ae?<div>Substitution failure occurs in &quot;<span style=3D"line-height: 1.=
2em; color: rgb(0, 0, 0); font-family: DejaVuSans, &#39;DejaVu Sans&#39;, a=
rial, sans-serif; font-size: 12.8px;">all expressions used in the function =
type&quot; quoting cppreference.com on SFINAE.</span><div><font color=3D"#0=
00000" face=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><span style=3D"f=
ont-size: 12.8px; line-height: 15.36px;">With p0012 accepted into C++17, th=
e noexcept specifier is a part of the function type, so this quote should b=
e changed to </span></font>&quot;<span style=3D"line-height: 1.2em; color: =
rgb(0, 0, 0); font-family: DejaVuSans, &#39;DejaVu Sans&#39;, arial, sans-s=
erif; font-size: 12.8px;">all expressions used in the function type except =
noexcept (I had to :)) specifier&quot; ?</span></div><div><font color=3D"#0=
00000" face=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><span style=3D"f=
ont-size: 12.8px; line-height: 15.36px;">Is it only because of those s</spa=
n></font><span style=3D"color: rgb(0, 0, 0); font-family: DejaVuSans, &#39;=
DejaVu Sans&#39;, arial, sans-serif; font-size: 12.8px; line-height: 15.36p=
x;">ubtle</span><font color=3D"#000000" face=3D"DejaVuSans, DejaVu Sans, ar=
ial, sans-serif"><span style=3D"font-size: 12.8px; line-height: 15.36px;">=
=C2=A0breakages mentioned ?</span></font></div><div><font color=3D"#000000"=
 face=3D"DejaVuSans, DejaVu Sans, arial, sans-serif"><span style=3D"font-si=
ze: 12.8px; line-height: 15.36px;">T</span></font><span style=3D"color: rgb=
(0, 0, 0); font-family: DejaVuSans, &#39;DejaVu Sans&#39;, arial, sans-seri=
f; font-size: 12.8px; line-height: 15.36px;">urning a hard error into subst=
itution failure only &quot;breaks&quot; code that didn&#39;t compile in C++=
14 which is a NOT a breaking change in my book (exactly like C++11 expressi=
on SFINAE and p238r0 return type deduction SFINAE) so actually, what subtle=
 breakages?</span></div><div><span style=3D"font-size: 12.8px; line-height:=
 15.36px; color: rgb(0, 0, 0); font-family: DejaVuSans, &#39;DejaVu Sans&#3=
9;, arial, sans-serif;">I was actually surprised noexcept-specifier isn&#39=
;t a SFINAE context even in C++11/14 (when my compiler shouted at me), but =
maybe that&#39;s just me.</span></div><div><br>On Saturday, December 5, 201=
5 at 12:01:26 AM UTC+2, Matt Calabrese 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"><h1 style=3D"color:rgb(0,0,0);font-family:T=
inos;line-height:normal">I&#39;m very much in favor of making noexcept-ness=
 a part of the function type, but subtle details of this paper are not full=
y clear to me when looking at the specified changes and so I&#39;m unable t=
o say whether I&#39;d be in favor of those details. In particular, it would=
 be nice if this paper or the author explicitly addressed the following que=
stions:</h1><h1 style=3D"color:rgb(0,0,0);font-family:Tinos;line-height:nor=
mal"><br></h1><h1 style=3D"color:rgb(0,0,0);font-family:Tinos;line-height:n=
ormal">Does this affect when the noexcept specification of a function is ev=
aluated in a way that can break existing code, especially if the noexcept s=
pecification deals with dependent types?</h1><h1 style=3D"color:rgb(0,0,0);=
font-family:Tinos;line-height:normal"><br></h1><h1 style=3D"color:rgb(0,0,0=
);font-family:Tinos;line-height:normal">Does this implicitly change anythin=
g regarding SFINAE, is that intentional with rationale, or is this incident=
al? From examining the proposed changes, my understanding is that nothing h=
ere explicitly changes with respect to SFINAE, so expressions appearing in =
the noexcept specification would cause a hard error if overload resolution =
would yield an instantiation of a function template declaration that has a =
noexcept specifier with an expression that would otherwise have caused SFIN=
AE had that expression appeared in the return type/parameter list/template =
parameter list. Is this a correct assessment? If so, this is probably=C2=A0=
the safest route forward to not risk subtle breakages and I am in favor of =
it, but I&#39;m not 100% sure that this is the effect of the proposal, so I=
&#39;d like some clarification.</h1><div><br></div><div>There is also an ex=
ample case that I&#39;m curious about:</div><div><br></div><div>//////////<=
/div><div><div>template &lt;class T&gt;</div><div>struct foo {</div>=C2=A0=
=C2=A0typename T::type=C2=A0bar();<div>=C2=A0 void baz() noexcept(noexcept(=
typename T::type{}));</div><div>};</div></div><div>//////////</div><div><br=
></div><div>In current C++, this code would produce a compile-time error si=
mply by instantiating foo&lt;int&gt; without using &quot;bar&quot;. However=
, this would <i>not</i> produce a hard error for &quot;baz&quot; if foo&lt;=
int&gt; were instantiated. Does the fact that the noexcept-ness is now a pa=
rt of the function type implicitly change the above code such that instanti=
ating foo&lt;int&gt; would be an error even if &quot;baz&quot; isn&#39;t in=
voked? My current understanding of the proposal is that this code would <i>=
not</i> change in the sense that &quot;baz&quot; would continue to not caus=
e a hard error merely by instantiating foo&lt;int&gt;, since the full funct=
ion type is not always determined at that time. If I&#39;m wrong and the pr=
oposal would now make foo&lt;int&gt; have a hard error because of &quot;baz=
&quot;, is it possible to make it such that this code wouldn&#39;t break?</=
div><div><br></div><div>Thanks.</div></div></blockquote></div></div></div>

<p></p>

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

------=_Part_367_923657735.1461198768110--
------=_Part_366_1372494366.1461198768110--

.

On 04/21/2016 02:32 AM, Omer Rosler wrote:
> But isn't that inconsistent with C++11 expression sfinae?
> Substitution failure occurs in "all expressions used in the function type" quoting cppreference.com on SFINAE.

Well, cppreference.com isn't the normative text.

> With p0012 accepted into C++17, the noexcept specifier is a part of the function type, so this quote should be changed to "all expressions used in the function type except noexcept (I had to :)) specifier" ?

"other than the exception-specification".  Yes, that sounds reasonable.

> Is it only because of those subtle breakages mentioned ?

Well, the existing standard text makes it clear that exception-specifications
are not instantiated right away, but only "when needed".  Together with
the fact that you can't overload on "noexcept(true)" vs. "noexcept(false)",
there isn't really any need to instantiate the exception-specification
during overload resolution for a function call.

Obviously, in a case like this:

  void (*fp)() = &f;

We need an instantiation of the exception-specification of "f" to determine
whether it matches the function pointer's exception specification, but that
is no change from the C++11 / C++14 situation.

Jens

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5719325C.1010202%40gmx.net.

.

------=_Part_1480_460378870.1461279454537
Content-Type: multipart/alternative;
 boundary="----=_Part_1481_17281376.1461279454537"

------=_Part_1481_17281376.1461279454537
Content-Type: text/plain; charset=UTF-8



On Thursday, April 21, 2016 at 4:04:48 PM UTC-4, Jens Maurer wrote:
>
> On 04/21/2016 02:32 AM, Omer Rosler wrote:
> > But isn't that inconsistent with C++11 expression sfinae?
> > Substitution failure occurs in "all expressions used in the function
> type" quoting cppreference.com on SFINAE.
>
> Well, cppreference.com isn't the normative text.
>

[temp.deduct]/7, as of today:

The substitution occurs in all types and expressions that are used in the
function type and in template parameter declarations.


>
>
> > With p0012 accepted into C++17, the noexcept specifier is a part of the
> function type, so this quote should be changed to "all expressions used in
> the function type except noexcept (I had to :)) specifier" ?
>
> "other than the exception-specification".  Yes, that sounds reasonable.
>
> > Is it only because of those subtle breakages mentioned ?
>
> Well, the existing standard text makes it clear that
> exception-specifications
> are not instantiated right away, but only "when needed".  Together with
> the fact that you can't overload on "noexcept(true)" vs.
> "noexcept(false)",
> there isn't really any need to instantiate the exception-specification
> during overload resolution for a function call.
>
> Obviously, in a case like this:
>
>   void (*fp)() = &f;
>
> We need an instantiation of the exception-specification of "f" to
> determine
> whether it matches the function pointer's exception specification, but
> that
> is no change from the C++11 / C++14 situation.
>


What's the intended treatment for an example like

template<class T> void f(T*) noexcept(some-complex-expression-dependent-on-T
);
template<class T> void f(T) noexcept;


void g(void (*)(int *) noexcept);
g(&f);
?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/92a7f50b-4dc2-426d-b1aa-ff677800d0ad%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, April 21, 2016 at 4:04:48 PM UTC-4, J=
ens Maurer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 04/21/2016=
 02:32 AM, Omer Rosler wrote:
<br>&gt; But isn&#39;t that inconsistent with C++11 expression sfinae?
<br>&gt; Substitution failure occurs in &quot;all expressions used in the f=
unction type&quot; quoting <a href=3D"http://cppreference.com" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFfMEVsriPdiSLWG49XWK9zX_c5Ug&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcppreference.com\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFfMEVsriPdiSLWG49XWK9zX_c5Ug&#39;;return =
true;">cppreference.com</a> on SFINAE.
<br>
<br>Well, <a href=3D"http://cppreference.com" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3=
A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFfMEVsriPdi=
SLWG49XWK9zX_c5Ug&#39;;return true;" onclick=3D"this.href=3D&#39;http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNFfMEVsriPdiSLWG49XWK9zX_c5Ug&#39;;return true;">cppreferenc=
e.com</a> isn&#39;t the normative text.
<br></blockquote><div><br></div><div>[temp.deduct]/7, as of today:</div><di=
v><br></div>The substitution occurs in all types and expressions that are u=
sed in the function type and in template parameter declarations.<div><br>=
=C2=A0 <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; With p0012 accepted into C++17, the noexcept specifier is a part o=
f the function type, so this quote should be changed to &quot;all expressio=
ns used in the function type except noexcept (I had to :)) specifier&quot; =
?
<br>
<br>&quot;other than the exception-specification&quot;. =C2=A0Yes, that sou=
nds reasonable.
<br>
<br>&gt; Is it only because of those subtle breakages mentioned ?
<br>
<br>Well, the existing standard text makes it clear that exception-specific=
ations
<br>are not instantiated right away, but only &quot;when needed&quot;. =C2=
=A0Together with
<br>the fact that you can&#39;t overload on &quot;noexcept(true)&quot; vs. =
&quot;noexcept(false)&quot;,
<br>there isn&#39;t really any need to instantiate the exception-specificat=
ion
<br>during overload resolution for a function call.
<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Obviously, in=
 a case like this:
<br>
<br>=C2=A0 void (*fp)() =3D &amp;f;
<br>
<br>We need an instantiation of the exception-specification of &quot;f&quot=
; to determine
<br>whether it matches the function pointer&#39;s exception specification, =
but that
<br>is no change from the C++11 / C++14 situation.
<br></blockquote><div><br></div><div><br></div><div>What&#39;s the intended=
 treatment for an example like</div><div><br></div><div class=3D"prettyprin=
t" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; ba=
ckground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-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=
"> noexcept</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">some</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">-</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">complex</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">-</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">expression</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">-</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">dependent</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">-</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">on</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">-</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">template</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> g</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(*)(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>g</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">f</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div><div>?</div></div></div>

<p></p>

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

------=_Part_1481_17281376.1461279454537--
------=_Part_1480_460378870.1461279454537--

.