noexcept move on containers (e.g. list)

[Marc Glisse]

On Wed, 18 Sep 2013, Daniel Krügler wrote:

>> On Wed, 18 Sep 2013, Daniel Krügler wrote:
>>
>>>> On 18 September 2013 09:58, Jonathan Wakely <jwakely.gcc@gmail.com>
>>>> wrote:
>>>
>>> [..]
>>>>
>>>> Although as you're asking specifically about move constructors (which
>>>> I don't think we check any preconditions on anyway) I don't know why
>>>> the standard considers them to have narrow contracts.
>>>
>>>
>>> I'm pretty sure that this wasn't the intention of N3279 to imply. To
>>> my knowledge the reason why the move constructors of containers are
>>> not noexcept, is because the default constructors aren't and this
>>> again was due to some existing implementations that could throw (in
>>> rare situations).
>>
>>
>> As far as I can see, an allocator's default constructor, if it exists, is
>> allowed to throw (as opposed to its move constructor which isn't), which
>> implies the same for a container using this allocator. So the default
>> constructor can't be made noexcept, while the move constructor could,
>> although that would prevent an implementation from using a short-string-like
>> optimization in those containers (I didn't check if that was already illegal
>> for other reasons).
>
> Ah, yes, I think you are right: Presumably for that reason
> allocator_traits::select_on_container_copy_construction has no
> noexcept specifier either. On the other hand, allocator[_traits]'s
> destroy function is also not noexcept and I believe that having no
> guarantee that these latter functions never throw looks like a defect
> of the library specification to me.

Yes, I wondered about that. Since destructors are guaranteed not to throw, 
I may have extrapolated that destroy wouldn't either in my latest patch... 
(though the code was already making this assumption in other places)

It would be good to add the corresponding line to the standard. Can you 
handle the new issue, Daniel? Or do you want me to try and write a few 
lines?

-- 
Marc Glisse