------=_Part_3367_659816805.1449266486211
Content-Type: multipart/alternative;
 boundary="----=_Part_3368_96934760.1449266486211"

------=_Part_3368_96934760.1449266486211
Content-Type: text/plain; charset=UTF-8

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><h1 style=3D"color: rgb(0, 0, 0); font-family: Tinos; 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 fully clear=
 to me when looking at the specified changes and so I&#39;m unable to say w=
hether I&#39;d be in favor of those details. In particular, it would be nic=
e if this paper or the author explicitly addressed the following questions:=
</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-h=
eight: normal;">Does this affect when the noexcept specification of a funct=
ion is evaluated in a way that can break existing code, especially if the n=
oexcept specification deals with dependent types?</h1><h1 style=3D"color: r=
gb(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 thi=
s implicitly change anything regarding SFINAE, is that intentional with rat=
ionale, or is this incidental? From examining the proposed changes, my unde=
rstanding is that nothing here explicitly changes with respect to SFINAE, s=
o expressions appearing in the noexcept specification would cause a hard er=
ror if overload resolution would yield an instantiation of a function templ=
ate declaration that has a noexcept specifier with an expression that would=
 otherwise have caused SFINAE had that expression appeared in the return ty=
pe/parameter list/template parameter list. Is this a correct assessment? If=
 so, this is probably=C2=A0the safest route forward to not risk subtle brea=
kages and I am in favor of it, but I&#39;m not 100% sure that this is the e=
ffect of the proposal, so I&#39;d like some clarification.</h1><div><br></d=
iv><div>There is also an example case that I&#39;m curious about:</div><div=
><br></div><div>//////////</div><div><div>template &lt;class T&gt;</div><di=
v>struct foo {</div>=C2=A0=C2=A0typename T::type=C2=A0bar();<div>=C2=A0 voi=
d baz() noexcept(noexcept(typename T::type{}));</div><div>};</div></div><di=
v>//////////</div><div><br></div><div>In current C++, this code would produ=
ce a compile-time error simply by instantiating foo&lt;int&gt; without usin=
g &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 part of the function type implicitly change the abo=
ve code such that instantiating foo&lt;int&gt; would be an error even if &q=
uot;baz&quot; isn&#39;t invoked? My current understanding of the proposal i=
s that this code would <i>not</i> change in the sense that &quot;baz&quot; =
would continue to not cause a hard error merely by instantiating foo&lt;int=
&gt;, since the full function type is not always determined at that time. I=
f I&#39;m wrong and the proposal 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>

<p></p>

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

------=_Part_3368_96934760.1449266486211--
------=_Part_3367_659816805.1449266486211--

.