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

[Akim Demaille]

Christian,

> Le 30 janv. 2021 à 20:14, Christian Schoenebeck <schoenebeck@crudebyte.com> a 
> écrit :
> 
> On Samstag, 30. Januar 2021 18:10:32 CET Akim Demaille wrote:
> 
>>> Le 19 janv. 2021 à 13:36, Christian Schoenebeck <schoenebeck@crudebyte.com> 
>>> a écrit :
>>> 
>>> 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".

Ok.

>> 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.

I was referring to move_if_noexcept for the callers, not for this
constructor.

Your initial message seemed to suggest to not define a move-ctor
that is not noexcept.  I was answering that I can see how this
requirement would be useful for the callers.  But AFAICT C++ does
not require that from the callee; however it provides the callers with
move_if_noexcept.

So it is my understanding that the *callers* should use move_if_noexcept.


However the move-ctor itself does not have to (and, I believe, should
not) use move_to_noexcept.  This ctor properly declares that it
might throw if one of the moves throws.  It would be weird to
declare noexcept(false) and be actually noexcept because we don't
depend on the corresponding move.


>> 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.

I filed a PR (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98899).

Cheers!