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

I decided to go with the original solution shown in the PR.

Tested powerpc64le-linux, committed to trunk.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 10797 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20170112/d6dbe92b/attachment.bin>