C++ no except updates

[nick]

On 2019-05-07 5:45 a.m., Jonathan Wakely wrote:
> Removing the gcc@ list, as there's no need to cross-post this to two
> lists.
> 
> 
> On 07/05/19 00:17 -0400, nick wrote:
>> Jonathan,
>>
>> I don't know what work is remaining in my ideas with inlining r value functions as you
> 
> I don't know what work you're referring to.
>
If I recall that was done with the C++20 filesystem and perhaps new networking
classes. You sent a patch to the list if I recall. 
 
> If you mean https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02618.html
> then that patch was simply wrong, and not needed.
> 
>> seemed to have already taken up and probably finished my ideas from reading the list.
>> If you want help finishing it just send me a ToDO of since C++11 and C++20 classes have
>> not been made noexcept for the move constructor and assignment operator.
> 
> I'm not going to perform such an audit for you. The types I'm aware of
> that have potentially throwing moves are like that for a reason, and
> need to stay that way.
> 
> 
No of course not this was your actually wording,

We'll consider any patches that add noexcept appropriately.

It's not always worth doing though. For constructors it can matter,
because it can affect the result of the is_nothrow_xxx_constructible
traits, which can cause different code paths to be taken elsewhere in
the library. For arbitrary member functions it doesn't usually make a
difference. The compiler can already see that most inline functions
can't throw, and so can already optimize accordingly.

I suggest a series of patches, split along sensible lines (i.e. don't
propose changes to unrelated types like std::basic_string and
std::atomic in the same patch, which is always good advice anyway).

Be aware that GCC is in Stage 3 of its development cycle, and changes
like this which do not fix any bugs are probably going to have to wait
for the next Stage 1. See https://gcc.gnu.org/develop.html#stage1 for
more information.


So I was just wondering if anything really changed other than the work on the noexcept adding to
the file system class was my point. Haven't been keeping up with the C++ standard library
side of gcc so was wondering if I'm correct in that being the only really class changed?

Nick