Re: Possible to declare move constructor of basic_symbol as noexcept?

[Christian Schoenebeck]

On Samstag, 30. Januar 2021 18:10:32 CET Akim Demaille wrote:
> Hi Christian,
> 
> I don't know how I managed to not see your answer about this,
> but I just discovered it, when I was about to ask for more
> feedback...

My good old camouflage emails. Np, Akim. :)

> > Le 19 janv. 2021 à 13:36, Christian Schoenebeck 
<schoenebeck@crudebyte.com> a écrit :
> >> diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4
> >> index cfd4e6ed7..3496450e2 100644
> >> --- a/data/skeletons/c++.m4
> >> +++ b/data/skeletons/c++.m4
> >> @@ -309,7 +309,9 @@ m4_define([b4_symbol_type_define],
> >> 
> >> #if 201103L <= YY_CPLUSPLUS
> >> 
> >>       /// Move constructor.
> >> 
> >> -      basic_symbol (basic_symbol&& that)
> >> +      basic_symbol (basic_symbol&& that)]b4_variant_if([
> >> +        YY_NOEXCEPT
> >> (]b4_type_foreach([b4_is_nothrow_move_constructible],
> >> [[ +                     && ]])[)])[
> >> 
> >>         : Base (std::move (that))
> >>         
> >>         , value (]b4_variant_if([], [std::move
> > 
> > AFAICS you are conditionally inserting the C++ 'noexcept' qualifier to
> > class "basic_symbol"'s constructor (by using C++ type trait
> > std::is_nowthrow_move_constructible()), and at the same time you are still
> > always using std::move() below though.
> 
> I'm unsure which "conditionally" you are referring to.  The
> macro YY_NOEXCEPT is conditioned by whether this is at least
> C++11.  Which is useless in the present case since we are
> already within "#if 201103L <= YY_CPLUSPLUS".  I'll simplify
> that.
> 
> And the noexcept itself depends on whether all the types
> support nothrow move-construction.

Yes, that's how I was reading it as well then.

> > that should be
> > either noexcept & std::move() otherwise no std::move() at all, at least
> > with recent compilers.
> 
> Really?  What mandates that?  I can see it is good style,

Yeah, I had a quick lookup and did not see it specified either. From my memory 
the idea was if an exception was thrown while std::move() is in progress, then 
it may leave it in an "undefined state".

> but the standard library is expected to use things such as
> move_if_noexcept to relieve us from having to not define
> move ctors in this case.

Yes, but in your patch you were not using std::move_if_noexcept() which is a 
wrapper for conditionally using std::move() if its nothrow, otherwise it 
automatically uses a temporary value for safety instead.

> And if that's true, that would mean
> I'd have to play ninja tricks (read sfinae) to do that, and I'm
> no longer in that mood :(  If someone wants to tell me what is
> expected in replacement of

Well, you already came up with an obvious approach; using 
std::move_if_noexcept() instead of std::move().

Whether that was actually the cause of the compiler crash you got there is 
another question, as I don't have a reproducer.

Best regards,
Christian Schoenebeck