2013/6/11 R=F3bert D=E1vid <lrdxgm@gmail.com>:
> Hello,
>
> I just noticed that in the last draft, std::optional<T> has a move
> constructor that is nothrow(is_nothrow_move_constructible<T>::value), and
> has a move-assignment operator that is
> nothrow(is_nothrow_move_assignable<T>::value &&
> is_nothrow_move_constructible<T>::value) (I think move-constructable for =
the
> case of assigning to a disengaged object).
>
> Now, there are no similar requirements for the copy constructor. Is there
> any reason why is it not nothrow(is_nothrow_copy_constructible<T>::value)=
,
> and similarly for the move-assignment operator?

The rationale for the lack of this specification is that during the
introduction of noexcept in the library it was decided that
move-operations and swap operations are (a) often noexcept and (b)
fundamental enough to justify that they will always get a - possibly
conditional - exception specification. Copying is fundamental, but it
generally has not a fundamental restriction to be noexcept (see the
special assumptionas that the library can make, if move operations may
throw exceptions).

See also

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

were a set of guidelines was suggested.

- 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

--089e0158ba12bd8f0504dee658e2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'll add that it was specifically brought up (twice I believe) during the
optional discussions.  So it was considered. (And once agreed, then later
disagreed.)

I think there was a general consensus that we should revisit the guidelines
in regards to at least *allowing* library classes to have conditional
noexcept copy constructors.  But that that should be a separate discussion,
and when/if that happens, then optional can be updated along with various
other classes.

Tony



On Tue, Jun 11, 2013 at 3:56 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com>wrote:

> 2013/6/11 R=F3bert D=E1vid <lrdxgm@gmail.com>:
> > Hello,
> >
> > I just noticed that in the last draft, std::optional<T> has a move
> > constructor that is nothrow(is_nothrow_move_constructible<T>::value), a=
nd
> > has a move-assignment operator that is
> > nothrow(is_nothrow_move_assignable<T>::value &&
> > is_nothrow_move_constructible<T>::value) (I think move-constructable fo=
r
> the
> > case of assigning to a disengaged object).
> >
> > Now, there are no similar requirements for the copy constructor. Is the=
re
> > any reason why is it not
> nothrow(is_nothrow_copy_constructible<T>::value),
> > and similarly for the move-assignment operator?
>
> The rationale for the lack of this specification is that during the
> introduction of noexcept in the library it was decided that
> move-operations and swap operations are (a) often noexcept and (b)
> fundamental enough to justify that they will always get a - possibly
> conditional - exception specification. Copying is fundamental, but it
> generally has not a fundamental restriction to be noexcept (see the
> special assumptionas that the library can make, if move operations may
> throw exceptions).
>
> See also
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf
>
> were a set of guidelines was suggested.
>
> - 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>
>
>

--=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/?hl=3Den.



--089e0158ba12bd8f0504dee658e2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;ll add that it was specifically brought up (twi=
ce I believe) during the optional discussions.=A0 So it was considered. (An=
d once agreed, then later disagreed.)<br><br></div>I think there was a gene=
ral consensus that we should revisit the guidelines in regards to at least =
*allowing* library classes to have conditional noexcept copy constructors.=
=A0 But that that should be a separate discussion, and when/if that happens=
, then optional can be updated along with various other classes.<br>
<br>Tony<br><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On Tue, Jun 11, 2013 at 3:56 PM, Daniel Kr=FCgler <span dir=3D"ltr=
">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel=
..kruegler@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/6/11 R=F3bert D=E1vid &lt;<a href=3D"ma=
ilto:lrdxgm@gmail.com">lrdxgm@gmail.com</a>&gt;:<br>
<div class=3D"im">&gt; Hello,<br>
&gt;<br>
&gt; I just noticed that in the last draft, std::optional&lt;T&gt; has a mo=
ve<br>
&gt; constructor that is nothrow(is_nothrow_move_constructible&lt;T&gt;::va=
lue), and<br>
&gt; has a move-assignment operator that is<br>
&gt; nothrow(is_nothrow_move_assignable&lt;T&gt;::value &amp;&amp;<br>
&gt; is_nothrow_move_constructible&lt;T&gt;::value) (I think move-construct=
able for the<br>
&gt; case of assigning to a disengaged object).<br>
&gt;<br>
&gt; Now, there are no similar requirements for the copy constructor. Is th=
ere<br>
&gt; any reason why is it not nothrow(is_nothrow_copy_constructible&lt;T&gt=
;::value),<br>
&gt; and similarly for the move-assignment operator?<br>
<br>
</div>The rationale for the lack of this specification is that during the<b=
r>
introduction of noexcept in the library it was decided that<br>
move-operations and swap operations are (a) often noexcept and (b)<br>
fundamental enough to justify that they will always get a - possibly<br>
conditional - exception specification. Copying is fundamental, but it<br>
generally has not a fundamental restriction to be noexcept (see the<br>
special assumptionas that the library can make, if move operations may<br>
throw exceptions).<br>
<br>
See also<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pd=
f" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
1/n3279.pdf</a><br>
<br>
were a set of guidelines was suggested.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0158ba12bd8f0504dee658e2--

.

------=_Part_511_2515191.1370982288785
Content-Type: text/plain; charset=ISO-8859-1



> The rationale for the lack of this specification is that
>

Is it a lack of specification for noexcept or a specification of lack of
noexcept for the constructors (and all other functions, as mentioned in
n3279)? As I understand it's the second.

N3279 suggest C compatibility functions to "may be marked unconditionally
noexcept.", and "No other function (than destructors, functions with wide
contract, move-constructors/-assignment ops) should use a conditional
noexcept specification", what might be too strict (for instance, for
optional). Is this because there was no better agreement of that time?

Robert

--

---
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/?hl=en.



------=_Part_511_2515191.1370982288785
Content-Type: text/html; charset=ISO-8859-1
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;">The rationale for the lack=
 of this specification is that <br></blockquote><div><br>Is it a lack of sp=
ecification for noexcept or a specification of lack of noexcept for the con=
structors (and all other functions, as mentioned in n3279)? As I understand=
 it's the second.<br><br>N3279 suggest C compatibility functions to "may be=
 marked unconditionally noexcept.", and "No other function (than destructor=
s, functions with wide contract, move-constructors/-assignment ops) should =
use a conditional noexcept specification", what might be too strict (for in=
stance, for optional). Is this because there was no better agreement of tha=
t time?<br><br>Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_511_2515191.1370982288785--

.

2013/6/11 R=F3bert D=E1vid <lrdxgm@gmail.com>:
>
>> The rationale for the lack of this specification is that
>
>
> Is it a lack of specification for noexcept or a specification of lack of
> noexcept for the constructors (and all other functions, as mentioned in
> n3279)? As I understand it's the second.

The point to decide on was: How much should the library specify,
especially since it just has introduced noexcept and a lot of work
would presumably arise to apply such rules consistently. Also it was
important to get a feeling upon the possible effect on compile-time, I
think. Therefore a set of guideline rules was suggested to help
deciding on noexcept.

> N3279 suggest C compatibility functions to "may be marked unconditionally
> noexcept.", and "No other function (than destructors, functions with wide
> contract, move-constructors/-assignment ops) should use a conditional
> noexcept specification", what might be too strict (for instance, for
> optional). Is this because there was no better agreement of that time?

I don't know what you mean by "better agreement". It was a set of
guidelines suggested and it was very helpful at that time. noexcept
was considered to be most important for good candidates for
potentially no-throwing operations and it should be hopefully easily
possible to express this condition (remember influence on
compile-time).

There is no reason not to to reconsider these rules in the future. I
suggest to publish a paper - similar to N3279 - that explains the
suggested extensions and the expected impact on the standard.

- 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.