public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [v3 PATCH] Slight cleanup of tuple constraints.
@ 2017-03-27 14:49 Ville Voutilainen
  2017-03-27 15:21 ` Jonathan Wakely
  0 siblings, 1 reply; 2+ messages in thread
From: Ville Voutilainen @ 2017-03-27 14:49 UTC (permalink / raw)
  To: libstdc++, gcc-patches, Dinka Ranns

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

This is not something that should go in at this stage, but I'm sending
it for review. Dinka quite astutely pointed out that the sizeof...(_Elements)>=1
tests seem unnecessary, and they are;

1) the helper aliases _TCC and _TMC already check that the incoming
pack and the element pack have the same size
2) if the element pack is empty, we wouldn't use these constructors
anyway, since we have a specialization for a zero-element tuple...
3) ...except that for the one taking const _Elements& we might, for
class template argument deduction cases, but we have a deduction
guide that deduces the zero-element specialization for 'tuple t;' so
we still won't use these constructors.

When stage1 for gcc 8 opens, I expect to clean up tuple's constraints
a bit anyway: there's no actual need to have, for instance, _ConstructibleTuple
and _MoveConstructibleTuple separately. However, that's a topic for another day,
as mentioned.

Tested on Linux-x64.

2017-03-27  Ville Voutilainen  <ville.voutilainen@gmail.com>

    Slight cleanup of tuple constraints.
    * include/std/tuple (tuple(const _Elements&...)): Strike
    the unnecessary sizeof... test.
    (tuple(_UElements&&...)): Likewise.
    * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust.

[-- Attachment #2: tuple-sizeof-cleanup.diff --]
[-- Type: text/plain, Size: 2816 bytes --]

diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 1f5365a..8af581c 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -602,8 +602,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
                  _TCC<_Dummy>::template
                    _ConstructibleTuple<_Elements...>()
                  && _TCC<_Dummy>::template
-                   _ImplicitlyConvertibleTuple<_Elements...>()
-                 && (sizeof...(_Elements) >= 1),
+                   _ImplicitlyConvertibleTuple<_Elements...>(),
                bool>::type=true>
         constexpr tuple(const _Elements&... __elements)
       : _Inherited(__elements...) { }
@@ -613,8 +612,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
                  _TCC<_Dummy>::template
                    _ConstructibleTuple<_Elements...>()
                  && !_TCC<_Dummy>::template
-                   _ImplicitlyConvertibleTuple<_Elements...>()
-                 && (sizeof...(_Elements) >= 1),
+                   _ImplicitlyConvertibleTuple<_Elements...>(),
                bool>::type=false>
       explicit constexpr tuple(const _Elements&... __elements)
       : _Inherited(__elements...) { }
@@ -640,8 +638,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 		  _TMC<_UElements...>::template
                     _MoveConstructibleTuple<_UElements...>()
                   && _TMC<_UElements...>::template
-                    _ImplicitlyMoveConvertibleTuple<_UElements...>()
-                  && (sizeof...(_Elements) >= 1),
+                    _ImplicitlyMoveConvertibleTuple<_UElements...>(),
         bool>::type=true>
         constexpr tuple(_UElements&&... __elements)
         : _Inherited(std::forward<_UElements>(__elements)...) { }
@@ -651,8 +648,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 		  _TMC<_UElements...>::template
                     _MoveConstructibleTuple<_UElements...>()
                   && !_TMC<_UElements...>::template
-                    _ImplicitlyMoveConvertibleTuple<_UElements...>()
-                  && (sizeof...(_Elements) >= 1),
+                    _ImplicitlyMoveConvertibleTuple<_UElements...>(),
         bool>::type=false>
         explicit constexpr tuple(_UElements&&... __elements)
 	: _Inherited(std::forward<_UElements>(__elements)...) {	}
diff --git a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
index 03835f4..6648d5e 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
@@ -17,7 +17,7 @@
 
 // { dg-options "-fno-show-column" }
 // { dg-do compile { target c++14 } }
-// { dg-error "in range" "" { target *-*-* } 1297 }
+// { dg-error "in range" "" { target *-*-* } 1293 }
 
 #include <tuple>
 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [v3 PATCH] Slight cleanup of tuple constraints.
  2017-03-27 14:49 [v3 PATCH] Slight cleanup of tuple constraints Ville Voutilainen
@ 2017-03-27 15:21 ` Jonathan Wakely
  0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Wakely @ 2017-03-27 15:21 UTC (permalink / raw)
  To: Ville Voutilainen; +Cc: libstdc++, gcc-patches, Dinka Ranns

On 27/03/17 17:44 +0300, Ville Voutilainen wrote:
>This is not something that should go in at this stage, but I'm sending
>it for review. Dinka quite astutely pointed out that the sizeof...(_Elements)>=1
>tests seem unnecessary, and they are;
>
>1) the helper aliases _TCC and _TMC already check that the incoming
>pack and the element pack have the same size
>2) if the element pack is empty, we wouldn't use these constructors
>anyway, since we have a specialization for a zero-element tuple...
>3) ...except that for the one taking const _Elements& we might, for
>class template argument deduction cases, but we have a deduction
>guide that deduces the zero-element specialization for 'tuple t;' so
>we still won't use these constructors.

Sounds right, so this looks good for Stage 1.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-03-27 15:12 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-27 14:49 [v3 PATCH] Slight cleanup of tuple constraints Ville Voutilainen
2017-03-27 15:21 ` Jonathan Wakely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).