From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-434047-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 49787 invoked by alias); 16 Aug 2016 11:52:39 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 49767 invoked by uid 89); 16 Aug 2016 11:52:38 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1051
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: mx1.redhat.com
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Aug 2016 11:52:37 +0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id 2C2A74E324;	Tue, 16 Aug 2016 11:52:36 +0000 (UTC)
Received: from localhost (ovpn-116-76.ams2.redhat.com [10.36.116.76])	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7GBqZjx007699;	Tue, 16 Aug 2016 07:52:35 -0400
Date: Tue, 16 Aug 2016 11:52:00 -0000
From: Jonathan Wakely <jwakely@redhat.com>
To: Ville Voutilainen <ville.voutilainen@gmail.com>
Cc: libstdc++ <libstdc++@gcc.gnu.org>,        "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,        Paolo Carlini <paolo.carlini@oracle.com>
Subject: Re: [v3 PATCH] Implement LWG 2758.
Message-ID: <20160816115234.GA20016@redhat.com>
References: <CAFk2RUZ1-wY57+4DUBQPfXkx46SjNSgFMKDqf-Syph3yF-qMGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CAFk2RUZ1-wY57+4DUBQPfXkx46SjNSgFMKDqf-Syph3yF-qMGQ@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.6.2 (2016-07-01)
X-SW-Source: 2016-08/txt/msg01172.txt.bz2

On 10/08/16 10:50 +0300, Ville Voutilainen wrote:
>diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
>index 59f1c64..89e2100 100644
>--- a/libstdc++-v3/include/bits/basic_string.h
>+++ b/libstdc++-v3/include/bits/basic_string.h
>@@ -1227,9 +1227,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>        *  @param __n   The number of characters to append from the string_view.
>        *  @return  Reference to this string.
>        */
>-      basic_string& append(__sv_type __sv,
>+      template <typename _Tp,
>+		enable_if_t<is_convertible_v<const _Tp&, __sv_type>,
>+			    bool> = true>
>+      basic_string& append(const _Tp& __svt,
> 			   size_type __pos, size_type __n = npos)

I would prefer the enable_if constraint to be on the return type, so
there is only one template parameter:

      template <typename _Tp>
        enable_if_t<is_convertible_v<const _Tp&, __sv_type>, basic_string&>
        append(const _Tp& __svt,
               size_type __pos, size_type __n = npos)

However these function templates appear to have a design problem, see
PR 77264.