This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3 PATCH] Implement the missing bits of LWG 2769
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 26 Feb 2018 20:52:20 +0000
- Subject: Re: [v3 PATCH] Implement the missing bits of LWG 2769
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUYrttM2F1X0sTuWyNZWDpYx2Eqam5ny8qzqYp14o5uHmg@mail.gmail.com>
On 25/02/18 23:22 +0200, Ville Voutilainen wrote:
Tested partially on Linux-x64, will test with the full suite on Linux-PPC64.
Ok for trunk and the gcc-7 branch? This is theoretically a breaking change
for the branch, but the committee has decided that they don't want
the support for copyable-but-not-movable types.
2018-02-25 Ville Voutilainen <ville.voutilainen@gmail.com>
Implement the missing bits of LWG 2769
* include/std/any (any_cast(const any&)): Add static_assert.
(any_cast(any&)): Likewise.
(any_cast(any&&)): Likewise, and remove the handling
for copyable-but-not-movable type.
* testsuite/20_util/any/misc/any_cast.cc: Adjust.
* testsuite/20_util/any/misc/any_cast_neg.cc: Likewise, and
add new tests.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 466b7ca..e0aba3c 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -455,6 +455,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
static_assert(any::__is_valid_cast<_ValueType>(),
"Template argument must be a reference or CopyConstructible type");
+ static_assert(is_constructible_v<_ValueType,
+ const _AnyCast<_ValueType>&>,
This template argument should be aligned with "_ValueType" on the
previous line, not with "is_constructible".
Looking at that file, I'm also wondering if we want the alias _AnyCast
to be defined at namespace scope. It's only used in a few function
bodies, and its name is a bit misleading.
Could you just do:
using _Up = remove_cv_t<remove_reference_t<_ValueType>>;
in the four functions that use it?
Then I think the is_constructible specializations would fit on one line
anyway.
But those are just stylistic issues, the technical side of the patch
is fine. I had to look up why we had two overloads for any_cast(any&&)
and that seems to be a leftover from experimental::any, so thanks for
cleaning that up too.