------=_Part_337_1327420454.1469710870396
Content-Type: multipart/alternative;
 boundary="----=_Part_338_805864187.1469710870397"

------=_Part_338_805864187.1469710870397
Content-Type: text/plain; charset=UTF-8

I propose a refinement of std::optional interface. The interface itself, in
my opinion, lacks some clear noexcept specifications. For example:

std::optional<int> o1;

std::optional<int> o2(o1); // no noexcept for copy-ctor implies this may
throw,
                           // yet copying an int cannot

std::optional<int> o3(std::move(o1)); // clear noexcept in line with actual
copying of an int

This simple example illustrates two problems:

1. Missing noexcept can popagate upwards, especially when optional is
contained inside another template, e.g.

template<class T>
struct Widget
{
    std::optional<T> o;

    // this will not be noexcept for Widget<int>, despite it never throws
    Widget(const Widget &other) noexcept(std::
is_nothrow_copy_constructible_v<std::optional<T>>)
    {
     ...
    }
};

2. These two constructors effectively perform the same action, yet one is
noexcept, the other is not.

I propose to add a proper noexcept-specification to copy and move ctors for
std::optional (where missing), assignment operators, emplace and value_or
methods, and operators (where applicable).

--
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/02471b9d-56fc-4ac2-b58f-7c10d74c81ce%40isocpp.org.

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

<div dir=3D"ltr">I propose a refinement of std::optional interface. The int=
erface itself, in my opinion, lacks some clear noexcept specifications. For=
 example:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">optional</=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> o1</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br>std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">optional</span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> o2</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">o1</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ no noexcept for copy-ctor implies this may throw,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><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</span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// yet copying a=
n int cannot</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><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<br>std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">optional</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> o3</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">move</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">o1</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// clear noexcept in line with actual copying of an=
 int</span></div></code></div><br>This simple example illustrates two probl=
ems:<br><br>1. Missing noexcept can popagate upwards, especially when optio=
nal is contained inside another template, e.g.<br><br><div class=3D"prettyp=
rint" 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"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
08;" 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"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Widg=
et</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</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"> o</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// this will not be noexcept for W=
idget&lt;int&gt;, despite it never throws</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Widget</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Widget</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">other<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">is_nothrow_copy_constructible_v</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">optional</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;&gt;)</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </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: #660;" class=3D"st=
yled-by-prettify">};</span></div></code></div><br>2. These two constructors=
 effectively perform the same action, yet one is noexcept, the other is not=
..<br><br>I propose to add a proper noexcept-specification to copy and move =
ctors for std::optional (where missing), assignment operators, emplace and =
value_or methods, and operators (where applicable).<br></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/02471b9d-56fc-4ac2-b58f-7c10d74c81ce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02471b9d-56fc-4ac2-b58f-7c10d74c81ce=
%40isocpp.org</a>.<br />

------=_Part_338_805864187.1469710870397--

------=_Part_337_1327420454.1469710870396--

.

2016-07-28 15:01 GMT+02:00  <kamil.rojewski@gmail.com>:
> I propose a refinement of std::optional interface. The interface itself, in
> my opinion, lacks some clear noexcept specifications. For example:

Your example focusing on std::optional is actually not an problem of
optional, but a consequence of the existing guide lines for the
Standard Library when conditional exception-specifications will be
provided, see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf

The thumb rule is that only swap and move operations are considered,
but not copy operations. If you want to change this, you should think
about a better general guide-line (with a good rationale) or you
should provide a weaker proposal that suggests to make exceptions of
the general rules as described in N3279 (again: With some good
rationale) but for specific types or families of types.

Keep in mind that the rules had been considered around the C++11
standardization where indeed a conservative rule made sense because of
the lack of the experience of the compile behaviour at that time. Now,
being near to C++17, it might make sense to reconsider the previous
guideline.

Thanks,

- Daniel

--
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/CAGNvRgAb4zdqO9y8EFhR_SUWKkuER%2BGdJAiC%2B3AXoLAqiLMaug%40mail.gmail.com.

.

------=_Part_292_706427181.1469786117176
Content-Type: multipart/alternative;
 boundary="----=_Part_293_967937821.1469786117176"

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

N3248 raised some valid concerns about the use of noexcept, and in my=20
opinion, those still hold, which leaves N3279 valid. But, it introduces=20
some problems. Some of them I outlined using std::optional as an example,=
=20
and I think those can be generalized for other std types as well. Those=20
become even more apparent when the lack of noexcept starts propagating=20
implicitly, e.g.

template<class T>
struct Widget
{
    std::optional<T> o;

    // variant 1: explicitly propagating lack of noexcept
    Widget(const Widget &) noexcept(std::is_nothrow_copy_constructible_v<st=
d
::optional<T>>) { ... }

    // variant 2: implicitly propagating lack of noexcept
    Widget(const Widget &) =3D default;
};


In both cases Widget<int> is not nothrow copy constructible. Given the=20
increasing use of defaulting special members (especially when following the=
=20
Rule of 3 or Rule of 5 patterns), we get improper noexcept propagation=20
potentially throughout the code. The burden to handle these situations will=
=20
lie on the hands of every programmer, who needs to both understand the=20
problem and know how to solve it.

Another problem is the lack of consistency. The accepted recommendation=20
treats moves and swaps specially, even when they have narrow contract.=20
While the motivation behind it is obvious, it still introduces=20
inconsistencies. Having such inconsistent interface can baffle=20
inexperienced programmers, which might get confused about the mechanism of=
=20
noexcept, and also is not future-proof. If more narrow contract methods=20
come to be, which should be accepted as conditionally noexcept, will there=
=20
be a vote on whether to treat them differently as well? This can only lead=
=20
to further inconsistencies.

This leaves noexcept in the standard library quite problematic. N3248=20
proposed a =E2=80=9Cpreferred additional recommendation=E2=80=9D, which see=
ms to solve this=20
problem, but it carries potentially non-trivial dependencies. I think there=
=20
should be a discussion about how to solve this issue.

On Thursday, July 28, 2016 at 3:14:51 PM UTC+2, Daniel Kr=C3=BCgler wrote:
>
> 2016-07-28 15:01 GMT+02:00  <kamil.r...@gmail.com <javascript:>>:=20
> > I propose a refinement of std::optional interface. The interface itself=
,=20
> in=20
> > my opinion, lacks some clear noexcept specifications. For example:=20
>
> Your example focusing on std::optional is actually not an problem of=20
> optional, but a consequence of the existing guide lines for the=20
> Standard Library when conditional exception-specifications will be=20
> provided, see=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf=20
>
> The thumb rule is that only swap and move operations are considered,=20
> but not copy operations. If you want to change this, you should think=20
> about a better general guide-line (with a good rationale) or you=20
> should provide a weaker proposal that suggests to make exceptions of=20
> the general rules as described in N3279 (again: With some good=20
> rationale) but for specific types or families of types.=20
>
> Keep in mind that the rules had been considered around the C++11=20
> standardization where indeed a conservative rule made sense because of=20
> the lack of the experience of the compile behaviour at that time. Now,=20
> being near to C++17, it might make sense to reconsider the previous=20
> guideline.=20
>
> Thanks,=20
>
> - Daniel=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d0e3a8fa-8c88-426c-9119-e02b75ee3457%40isocpp.or=
g.

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

<div dir=3D"ltr">N3248 raised some valid concerns about the use of noexcept=
, and in my opinion, those still hold, which leaves N3279 valid. But, it in=
troduces some problems. Some of them I outlined using std::optional as an e=
xample, and I think those can be generalized for other std types as well. T=
hose become even more apparent when the lack of noexcept starts propagating=
 implicitly, e.g.<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">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;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Widget</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">optional</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"s=
tyled-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-pretti=
fy"> o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// variant 1: explicitly propagating lack of noexcept</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Widget</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Widget</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&amp;)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> noexcept</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">is_nothrow_copy_c=
onstructible_v</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;&gt;)</span><span style=3D"col=
or: #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"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// variant 2: implicitly propagating lack of noexcept</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Widget</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Widget</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&amp;)</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"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">default</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">};</span></div></code></div><br>=
<br>In both cases Widget&lt;int&gt; is not nothrow copy constructible. Give=
n the increasing use of defaulting special members (especially when followi=
ng the Rule of 3 or Rule of 5 patterns), we get improper noexcept propagati=
on potentially throughout the code. The burden to handle these situations w=
ill lie on the hands of every programmer, who needs to both understand the =
problem and know how to solve it.<br><br>Another problem is the lack of con=
sistency. The accepted recommendation treats moves and swaps specially, eve=
n when they have narrow contract. While the motivation behind it is obvious=
, it still introduces inconsistencies. Having such inconsistent interface c=
an baffle inexperienced programmers, which might get confused about the mec=
hanism of noexcept, and also is not future-proof. If more narrow contract m=
ethods come to be, which should be accepted as conditionally noexcept, will=
 there be a vote on whether to treat them differently as well? This can onl=
y lead to further inconsistencies.<br><br>This leaves noexcept in the stand=
ard library quite problematic. N3248 proposed a =E2=80=9Cpreferred addition=
al recommendation=E2=80=9D, which seems to solve this problem, but it carri=
es potentially non-trivial dependencies. I think there should be a discussi=
on about how to solve this issue.<br><br>On Thursday, July 28, 2016 at 3:14=
:51 PM UTC+2, Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">2016-07-28 15:01 GMT+02:00 =C2=A0&lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"xXAMyWRuBQAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;">kamil.r...@gmail.com</a>&gt;:
<br>&gt; I propose a refinement of std::optional interface. The interface i=
tself, in
<br>&gt; my opinion, lacks some clear noexcept specifications. For example:
<br>
<br>Your example focusing on std::optional is actually not an problem of
<br>optional, but a consequence of the existing guide lines for the
<br>Standard Library when conditional exception-specifications will be
<br>provided, see
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n327=
9.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw&#39;;return true;">http://www.o=
pen-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2011/<wbr>n3279.pdf</a>
<br>
<br>The thumb rule is that only swap and move operations are considered,
<br>but not copy operations. If you want to change this, you should think
<br>about a better general guide-line (with a good rationale) or you
<br>should provide a weaker proposal that suggests to make exceptions of
<br>the general rules as described in N3279 (again: With some good
<br>rationale) but for specific types or families of types.
<br>
<br>Keep in mind that the rules had been considered around the C++11
<br>standardization where indeed a conservative rule made sense because of
<br>the lack of the experience of the compile behaviour at that time. Now,
<br>being near to C++17, it might make sense to reconsider the previous
<br>guideline.
<br>
<br>Thanks,
<br>
<br>- Daniel
<br></blockquote></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/d0e3a8fa-8c88-426c-9119-e02b75ee3457%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0e3a8fa-8c88-426c-9119-e02b75ee3457=
%40isocpp.org</a>.<br />

------=_Part_293_967937821.1469786117176--

------=_Part_292_706427181.1469786117176--

.

2016-07-29 11:55 GMT+02:00  <kamil.rojewski@gmail.com>:

> Another problem is the lack of consistency. The accepted recommendation
> treats moves and swaps specially, even when they have narrow contract.

I'm not against considering copy operations within constrained
exception-specifications, but I'm strongly opposed to your argument of
being inconsistent here:

The current guidelines surely *are* consistent, because they define a
set of testable criteria that give good guidance when to apply the
rule. And surely move and swappable operations do take the most
advantage of providing such an exception specification. For copy
operations some situations exists, but they are much rarer.

You may not like the outcome of it, but the outcome of the rules is
not a valid argument to argue that the rules are inconsistent.

- Daniel

--
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/CAGNvRgDEMo87sLwNshfprQDzn_r6_8XoyzXXkh1KfwRHoFq-zw%40mail.gmail.com.

.

------=_Part_179_669822890.1469790641261
Content-Type: multipart/alternative;
 boundary="----=_Part_180_1477082526.1469790641267"

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

I think you misunderstood me a bit. I'm not arguing the rules are=20
inconsistent - as you said, they define a clear criteria on how to apply=20
noexcept. I was talking about the resulting interface itself, where you=20
have to consider the "obviously noexcept" cases (wide contract), explicitly=
=20
non-noexcept cases (narrow contract), but also special cases of narrow=20
contract methods (moves, swap). This results in methods which could be=20
noexcept, but aren't, mixed with methods that are noexcept (conditional or=
=20
otherwise), depending on their "special" status. I think a much clearer=20
interface would be one of two: either nothing is noexcept (bad idea), or=20
each method can potentially have a conditional/unconditional noexcept=20
specifier.

But, as explained in N3248, this causes too many problems, on which I=20
agree. Again - I'm not against the rules themselves here. I just wish to=20
highlight a resulting problem. The question is - can/should something be=20
done?

On Friday, July 29, 2016 at 12:54:44 PM UTC+2, Daniel Kr=C3=BCgler wrote:
>
> 2016-07-29 11:55 GMT+02:00  <kamil.r...@gmail.com <javascript:>>:=20
>
> > Another problem is the lack of consistency. The accepted recommendation=
=20
> > treats moves and swaps specially, even when they have narrow contract.=
=20
>
> I'm not against considering copy operations within constrained=20
> exception-specifications, but I'm strongly opposed to your argument of=20
> being inconsistent here:=20
>
> The current guidelines surely *are* consistent, because they define a=20
> set of testable criteria that give good guidance when to apply the=20
> rule. And surely move and swappable operations do take the most=20
> advantage of providing such an exception specification. For copy=20
> operations some situations exists, but they are much rarer.=20
>
> You may not like the outcome of it, but the outcome of the rules is=20
> not a valid argument to argue that the rules are inconsistent.=20
>
> - Daniel=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5cedd80c-cc90-45a6-af28-4daaf64a4ae3%40isocpp.or=
g.

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

<div dir=3D"ltr">I think you misunderstood me a bit. I&#39;m not arguing th=
e rules are inconsistent - as you said, they define a clear criteria on how=
 to apply noexcept. I was talking about the resulting interface itself, whe=
re you have to consider the &quot;obviously noexcept&quot; cases (wide cont=
ract), explicitly non-noexcept cases (narrow contract), but also special ca=
ses of narrow contract methods (moves, swap). This results in methods which=
 could be noexcept, but aren&#39;t, mixed with methods that are noexcept (c=
onditional or otherwise), depending on their &quot;special&quot; status. I =
think a much clearer interface would be one of two: either nothing is noexc=
ept (bad idea), or each method can potentially have a conditional/unconditi=
onal noexcept specifier.<br><br>But, as explained in N3248, this causes too=
 many problems, on which I agree. Again - I&#39;m not against the rules the=
mselves here. I just wish to highlight a resulting problem. The question is=
 - can/should something be done?<br><br>On Friday, July 29, 2016 at 12:54:4=
4 PM UTC+2, Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">2016-07-29 11:55 GMT+02:00 =C2=A0&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"zQGR_FO1BQAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">kamil.r...@gmail.com</a>&gt;:
<br>
<br>&gt; Another problem is the lack of consistency. The accepted recommend=
ation
<br>&gt; treats moves and swaps specially, even when they have narrow contr=
act.
<br>
<br>I&#39;m not against considering copy operations within constrained
<br>exception-specifications, but I&#39;m strongly opposed to your argument=
 of
<br>being inconsistent here:
<br>
<br>The current guidelines surely *are* consistent, because they define a
<br>set of testable criteria that give good guidance when to apply the
<br>rule. And surely move and swappable operations do take the most
<br>advantage of providing such an exception specification. For copy
<br>operations some situations exists, but they are much rarer.
<br>
<br>You may not like the outcome of it, but the outcome of the rules is
<br>not a valid argument to argue that the rules are inconsistent.
<br>
<br>- Daniel
<br></blockquote></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/5cedd80c-cc90-45a6-af28-4daaf64a4ae3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cedd80c-cc90-45a6-af28-4daaf64a4ae3=
%40isocpp.org</a>.<br />

------=_Part_180_1477082526.1469790641267--

------=_Part_179_669822890.1469790641261--

.

2016-07-29 13:10 GMT+02:00 Kamil Rojewski <kamil.rojewski@gmail.com>:
> I think you misunderstood me a bit. I'm not arguing the rules are
> inconsistent

Yes, that sounds like a misunderstanding on my part.

- as you said, they define a clear criteria on how to apply
> noexcept. I was talking about the resulting interface itself, where you have
> to consider the "obviously noexcept" cases (wide contract), explicitly
> non-noexcept cases (narrow contract), but also special cases of narrow
> contract methods (moves, swap). This results in methods which could be
> noexcept, but aren't, mixed with methods that are noexcept (conditional or
> otherwise), depending on their "special" status. I think a much clearer
> interface would be one of two: either nothing is noexcept (bad idea), or
> each method can potentially have a conditional/unconditional noexcept
> specifier.
>
> But, as explained in N3248, this causes too many problems, on which I agree.
> Again - I'm not against the rules themselves here. I just wish to highlight
> a resulting problem. The question is - can/should something be done?

The intention of my original reply was to give provide exactly such a
method: I'm strongly arguing in preparing a proposal that either
suggests a general, more relaxed set of rules (That would include copy
operations - at least in some contexts) or that suggests to make
special exceptions of the rule for .....

My personal guess is that a paper that suggests a new rule set has
better chances of becoming accepted, but it would not be the first
time that I'm erring ;-)

To write such a proposal please read

https://isocpp.org/std/submit-a-proposal

and contact the lwgchair (see reply-to on this page:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html) if you
have any further questions regarding details of submitting a proposal.

Thanks,

- Daniel

--
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/CAGNvRgBTob%3DnJWP_B%2BLKBLunS_YW_Huqqs%3DBvCx4Qdz%2Bsh95Vg%40mail.gmail.com.

.

------=_Part_424_1024082630.1470248716730
Content-Type: multipart/alternative;
 boundary="----=_Part_425_2075232520.1470248716730"

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

On Thursday, July 28, 2016 at 3:14:51 PM UTC+2, Daniel Kr=C3=BCgler wrote:
>
> 2016-07-28 15:01 GMT+02:00  <kamil.r...@gmail.com <javascript:>>:=20
> > I propose a refinement of std::optional interface. The interface itself=
,=20
> in=20
> > my opinion, lacks some clear noexcept specifications. For example:=20
>
> Your example focusing on std::optional is actually not an problem of=20
> optional, but a consequence of the existing guide lines for the=20
> Standard Library when conditional exception-specifications will be=20
> provided, see=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf=20
>
> The thumb rule is that only swap and move operations are considered,=20
> but not copy operations. If you want to change this, you should think=20
> about a better general guide-line (with a good rationale) or you=20
> should provide a weaker proposal that suggests to make exceptions of=20
> the general rules as described in N3279 (again: With some good=20
> rationale) but for specific types or families of types.=20
>
> Keep in mind that the rules had been considered around the C++11=20
> standardization where indeed a conservative rule made sense because of=20
> the lack of the experience of the compile behaviour at that time. Now,=20
> being near to C++17, it might make sense to reconsider the previous=20
> guideline.=20
>

Knowing I'm late to the party, I just can't resist to add some thoughts.

'noexcept' says that the program will terminate the program if its promise=
=20
is violated. There was a time when this was controversial, but the=20
committee decided to bite the bullet and specify that that was the right=20
thing to do.

N3279 and N3248 are primarily concerned about testing whether a failing=20
precondition check triggers. For that, it must be possible to regain=20
control and verify that=20
the checking logic worked. The authors suggest that this is best served by=
=20
throwing a specific exception and see if it is caught.

Obviously, these choices are incompatible. You can't expect to catch an=20
exception thrown from a function that promises not to throw any. Hence the=
=20
resistance to adding 'noexcept' to function signatures that should not=20
throw, even when a clearly specified precondition is violated.

Taking a step back, while it may be difficult (impossible?) to check if a=
=20
program is terminated from within that same program, under most operating=
=20
systems, it is trivial to regain control and detect an abortive shutdown in=
=20
the environment that started the program. So this is where such a test=20
should be implemented.

Wil

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5b468c14-8027-455d-a7f5-f3cf91ce35b7%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, July 28, 2016 at 3:14:51 PM UTC+2, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-07-28 15=
:01 GMT+02:00 =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"xXAMyWRuBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">kamil.r...@gmail.com</a>&gt;:
<br>&gt; I propose a refinement of std::optional interface. The interface i=
tself, in
<br>&gt; my opinion, lacks some clear noexcept specifications. For example:
<br>
<br>Your example focusing on std::optional is actually not an problem of
<br>optional, but a consequence of the existing guide lines for the
<br>Standard Library when conditional exception-specifications will be
<br>provided, see
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n327=
9.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw&#39;;return true;">http://www.o=
pen-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2011/<wbr>n3279.pdf</a>
<br>
<br>The thumb rule is that only swap and move operations are considered,
<br>but not copy operations. If you want to change this, you should think
<br>about a better general guide-line (with a good rationale) or you
<br>should provide a weaker proposal that suggests to make exceptions of
<br>the general rules as described in N3279 (again: With some good
<br>rationale) but for specific types or families of types.
<br>
<br>Keep in mind that the rules had been considered around the C++11
<br>standardization where indeed a conservative rule made sense because of
<br>the lack of the experience of the compile behaviour at that time. Now,
<br>being near to C++17, it might make sense to reconsider the previous
<br>guideline.
<br>
</blockquote><div><br>Knowing I&#39;m late to the party, I just can&#39;t r=
esist to add some thoughts.<br><br>&#39;noexcept&#39; says that the program=
 will terminate the program if its=20
promise is violated. There was a time when this was controversial, but=20
the committee decided to bite the bullet and specify that that was the=20
right thing to do.<br><br>N3279 and N3248 are primarily concerned about tes=
ting whether a failing precondition check triggers. For that, it must be po=
ssible to regain control and verify that <br>the checking logic worked. The=
 authors suggest that this is best served by throwing a specific exception =
and see if it is caught.<br><br>Obviously, these choices are incompatible. =
You can&#39;t expect to catch an exception thrown from a function that prom=
ises not to throw any. Hence the resistance to adding &#39;noexcept&#39; to=
 function signatures that should not throw, even when a clearly specified p=
recondition is violated.<br><br>Taking a step back, while it may be difficu=
lt (impossible?) to check if a program is terminated from within that same =
program, under most operating systems, it is trivial to regain control and =
detect an abortive shutdown in the environment that started the program. So=
 this is where such a test should be implemented.<br><br>Wil<br><br></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/5b468c14-8027-455d-a7f5-f3cf91ce35b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b468c14-8027-455d-a7f5-f3cf91ce35b7=
%40isocpp.org</a>.<br />

------=_Part_425_2075232520.1470248716730--

------=_Part_424_1024082630.1470248716730--

.

------=_Part_215_916651716.1470292029239
Content-Type: multipart/alternative;
 boundary="----=_Part_216_1539051908.1470292029243"

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

I'm thinking about a general solution to this problem, and can't see any=20
apart from one already mentioned in N3248 - allow for=20
implementation-defined behavior when violating noexcept. This is far from=
=20
ideal - such behavior *could* render noexcept useless, or rather=20
"untrustworthy". Having a strong exception guarantee, without the need to=
=20
consult your compiler, is a much needed feature. On the other hand, as I=20
outlined before, this leads to inconsistent interfaces and improper=20
noexcept (or lack of) propagation.

Nevertheless, I still believe the Standard Library should be amended with=
=20
proper noexcepts for narrow contract functions. Yet, I don't have an answer=
=20
ready on how this could be achieved with minimal impact.

On Wednesday, August 3, 2016 at 8:25:17 PM UTC+2, Wil Evers wrote:
>
> On Thursday, July 28, 2016 at 3:14:51 PM UTC+2, Daniel Kr=C3=BCgler wrote=
:
>>
>> 2016-07-28 15:01 GMT+02:00  <kamil.r...@gmail.com>:=20
>> > I propose a refinement of std::optional interface. The interface=20
>> itself, in=20
>> > my opinion, lacks some clear noexcept specifications. For example:=20
>>
>> Your example focusing on std::optional is actually not an problem of=20
>> optional, but a consequence of the existing guide lines for the=20
>> Standard Library when conditional exception-specifications will be=20
>> provided, see=20
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf=20
>>
>> The thumb rule is that only swap and move operations are considered,=20
>> but not copy operations. If you want to change this, you should think=20
>> about a better general guide-line (with a good rationale) or you=20
>> should provide a weaker proposal that suggests to make exceptions of=20
>> the general rules as described in N3279 (again: With some good=20
>> rationale) but for specific types or families of types.=20
>>
>> Keep in mind that the rules had been considered around the C++11=20
>> standardization where indeed a conservative rule made sense because of=
=20
>> the lack of the experience of the compile behaviour at that time. Now,=
=20
>> being near to C++17, it might make sense to reconsider the previous=20
>> guideline.=20
>>
>
> Knowing I'm late to the party, I just can't resist to add some thoughts.
>
> 'noexcept' says that the program will terminate the program if its promis=
e=20
> is violated. There was a time when this was controversial, but the=20
> committee decided to bite the bullet and specify that that was the right=
=20
> thing to do.
>
> N3279 and N3248 are primarily concerned about testing whether a failing=
=20
> precondition check triggers. For that, it must be possible to regain=20
> control and verify that=20
> the checking logic worked. The authors suggest that this is best served b=
y=20
> throwing a specific exception and see if it is caught.
>
> Obviously, these choices are incompatible. You can't expect to catch an=
=20
> exception thrown from a function that promises not to throw any. Hence th=
e=20
> resistance to adding 'noexcept' to function signatures that should not=20
> throw, even when a clearly specified precondition is violated.
>
> Taking a step back, while it may be difficult (impossible?) to check if a=
=20
> program is terminated from within that same program, under most operating=
=20
> systems, it is trivial to regain control and detect an abortive shutdown =
in=20
> the environment that started the program. So this is where such a test=20
> should be implemented.
>
> Wil
>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4e3477be-eb69-4fdb-adac-74877ffa5996%40isocpp.or=
g.

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

<div dir=3D"ltr">I&#39;m thinking about a general solution to this problem,=
 and can&#39;t see any apart from one already mentioned in N3248 - allow fo=
r implementation-defined behavior when violating noexcept. This is far from=
 ideal - such behavior <i>could</i> render noexcept useless, or rather &quo=
t;untrustworthy&quot;. Having a strong exception guarantee, without the nee=
d to consult your compiler, is a much needed feature. On the other hand, as=
 I outlined before, this leads to inconsistent interfaces and improper noex=
cept (or lack of) propagation.<br><br>Nevertheless, I still believe the Sta=
ndard Library should be amended with proper noexcepts for narrow contract f=
unctions. Yet, I don&#39;t have an answer ready on how this could be achiev=
ed with minimal impact.<br><br>On Wednesday, August 3, 2016 at 8:25:17 PM U=
TC+2, Wil Evers 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">On Thursday, July 28, 2016 at 3:14:51 PM UTC+2, Daniel Kr=C3=BCgle=
r wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">2016-07-28 15:01 GMT+02:00 =
=C2=A0&lt;<a rel=3D"nofollow">kamil.r...@gmail.com</a>&gt;:
<br>&gt; I propose a refinement of std::optional interface. The interface i=
tself, in
<br>&gt; my opinion, lacks some clear noexcept specifications. For example:
<br>
<br>Your example focusing on std::optional is actually not an problem of
<br>optional, but a consequence of the existing guide lines for the
<br>Standard Library when conditional exception-specifications will be
<br>provided, see
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n327=
9.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2011%2Fn3279.pdf\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNFtBaj7afJRnnnusmmIo4mfR65Pnw&#39;;return true;">http://www.o=
pen-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2011/<wbr>n3279.pdf</a>
<br>
<br>The thumb rule is that only swap and move operations are considered,
<br>but not copy operations. If you want to change this, you should think
<br>about a better general guide-line (with a good rationale) or you
<br>should provide a weaker proposal that suggests to make exceptions of
<br>the general rules as described in N3279 (again: With some good
<br>rationale) but for specific types or families of types.
<br>
<br>Keep in mind that the rules had been considered around the C++11
<br>standardization where indeed a conservative rule made sense because of
<br>the lack of the experience of the compile behaviour at that time. Now,
<br>being near to C++17, it might make sense to reconsider the previous
<br>guideline.
<br>
</blockquote><div><br>Knowing I&#39;m late to the party, I just can&#39;t r=
esist to add some thoughts.<br><br>&#39;noexcept&#39; says that the program=
 will terminate the program if its=20
promise is violated. There was a time when this was controversial, but=20
the committee decided to bite the bullet and specify that that was the=20
right thing to do.<br><br>N3279 and N3248 are primarily concerned about tes=
ting whether a failing precondition check triggers. For that, it must be po=
ssible to regain control and verify that <br>the checking logic worked. The=
 authors suggest that this is best served by throwing a specific exception =
and see if it is caught.<br><br>Obviously, these choices are incompatible. =
You can&#39;t expect to catch an exception thrown from a function that prom=
ises not to throw any. Hence the resistance to adding &#39;noexcept&#39; to=
 function signatures that should not throw, even when a clearly specified p=
recondition is violated.<br><br>Taking a step back, while it may be difficu=
lt (impossible?) to check if a program is terminated from within that same =
program, under most operating systems, it is trivial to regain control and =
detect an abortive shutdown in the environment that started the program. So=
 this is where such a test should be implemented.<br><br>Wil<br><br></div><=
/div></blockquote></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/4e3477be-eb69-4fdb-adac-74877ffa5996%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e3477be-eb69-4fdb-adac-74877ffa5996=
%40isocpp.org</a>.<br />

------=_Part_216_1539051908.1470292029243--

------=_Part_215_916651716.1470292029239--

.