On Fri, 6 May 2016, Ville Voutilainen wrote:
On 6 May 2016 at 20:51, Marc Glisse <marc.gli...@inria.fr> wrote:
Hi Ville,
since you wrote the latest patches on tuple constructors, do you have an
opinion on this patch, or alternate strategies to achieve the same goal?
https://gcc.gnu.org/ml/libstdc++/2016-04/msg00041.html
I have fairly mixed feelings about the approach; it's adding a tag type
and more enable_ifs into the base classes of tuple, which I'd rather not
do unless absolutely necessary. Then again, the testcase you add looks
like something we want to support properly. I haven't analyzed your
patch in a very detailed manner; my initial thought was "can't we do
this in the constraints of tuple's constructors", but looking at the
patch and knowing the constructors of tuple, I don't think we can.
Assuming we want the copy constructor to be defaulted, I think we still
could with concepts:
tuple(tuple const&)
requires(__and_<is_copy_constructible<_Elements>...>::value)
= default;
While there is precedent for enabling C++11 features in C++03 mode inside
system headers, I guess maintainers might be more reluctant for something
that is only heading for a TS for now.
I think the patch is ok, but I think it would be a good idea to have a
comment on the added tag type and its purpose.
Indeed. I wasn't sure if people preferred more tags or more enable_if...
Minor point: the technique that looks like
typename enable_if<
!is_same<_UHead, _Head>::value, bool>::type = false
isn't necessary unless we have another overload that we need to
distinguish with true/false. For a single overload,
just using typename = typename enable_if<
!is_same<_UHead, _Head>::value, bool>::type
works equally well. The amount of boilerplate is more or less the
same, so that's really not a significant matter,
just an fyi. :)
Thanks. There are several variants on how to use enable_if, I copied one
from some neighboring code without checking why this specific variant was
used there.
--
Marc Glisse
