[PATCH] PR77528 add default constructors for container adaptors

[Jonathan Wakely]

On 11/01/17 13:25 +0000, Jonathan Wakely wrote:
>On 11/01/17 08:04 -0500, Tim Song wrote:
>>On Wed, Jan 11, 2017 at 7:21 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
>>>This patch uses the _Enable_default_constructor mixin to properly
>>>delete the default constructors. It's a bit cumbersome, because we
>>>have to add an initializer for the base class to every
>>>ctor-initializer-list, but I think I prefer this to making the default
>>>constructor a constrained template.
>>>
>>
>>I'm happy with either approach - my primary concern is making sure
>>that is_constructible and friends work and don't lie, in a world where
>>increasing numbers of library components depend on it. Though I'm a
>
>Yes, it's important that we give the right answer.
>
>>bit curious as to why you found this approach more preferable.
>
>I dislike making functions into templates when they aren't "supposed"
>to be. But I'm in two minds for this case. It's certainly a smaller,
>more self-contained change to just add a default constructor template
>and not mess about with a new base class and DMIs and all those
>mem-initializers.
>
>>Re the new DMI, my brain compiler says that _Sequence c = _Sequence();
>>breaks anything with an explicit copy/move constructor pre-C++17, but
>>I also don't think we care about those, right?
>
>I dislike them,

I meant to add "but we try to support them where plausible".

If the standard requires CopyConstructible then we don't need to care
about explicit copy constructors. But if it only requires
is_copy_constructible then that does work with explicit copy ctors.
And if it says one thing, but means the other, then we just have to
guess what's intended! :-)

>but maybe the fact they won't work here is a strong
>enough reason to get over my dislike of the original approach and just
>do it that way instead.
>
>