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