noexcept move on containers (e.g. list)

[Daniel Krügler]

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

- Daniel