From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59703 invoked by alias); 13 Mar 2017 10:56:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 59689 invoked by uid 89); 13 Mar 2017 10:56:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1686, H*i:CAGNvRgDeqGG, H*f:sk:39HVhs6, H*i:sk:39HVhs6 X-HELO: mail-yw0-f172.google.com Received: from mail-yw0-f172.google.com (HELO mail-yw0-f172.google.com) (209.85.161.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Mar 2017 10:56:13 +0000 Received: by mail-yw0-f172.google.com with SMTP id v198so56293195ywc.2 for ; Mon, 13 Mar 2017 03:56:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iFwdJysDXWCA5NE2Y4NsNTMjMtozDRCNrGxI5I5xvuk=; b=fWtlbfw5j81qqklJzj9ELA4YBXEnMm7bhSjs3m9yrm+EWtGqdERuHsYoGwh/iem4/h SD0+ocCC3j99yZbJVdQOebbYrFKuu814EPBCsxKWm7q9RKRHL1lcPpK3wfPKMmz6Rarv QUgSuioPKwhwhxUqwNEgjxVWtkDXEgR1I+tzU6Ze0K5x2vU9kkpCmutOCF0iVUeNddVP aarXFPA36x/YSlXOhO9zzKlyjAIzbTMlvjnIHwLREGv6MJBuwQLwx9tbxuU1NkjRrmkQ sKsIHOcufvuRQmRUzJsQQIm79rWMm515C8s0PDdd7MyFNncPeclXPORhxRWMNe3QXRHf 31GA== X-Gm-Message-State: AMke39kKAMIlkhqv2mYYY4wujphOuZzY/N0yWqZn20ARlJXYs31OprBYqvHNMb31+S5PI+BftnKlW6nPdENArQ== X-Received: by 10.129.90.198 with SMTP id o189mr18208973ywb.63.1489402573057; Mon, 13 Mar 2017 03:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.164.36 with HTTP; Mon, 13 Mar 2017 03:56:12 -0700 (PDT) In-Reply-To: References: From: Jonathan Wakely Date: Mon, 13 Mar 2017 10:56:00 -0000 Message-ID: Subject: Re: Design question LWG 2861: basic_string should require that charT match traits::char_type To: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= Cc: GCC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00054.txt.bz2 On 12 March 2017 at 13:21, Daniel Kr=C3=BCgler = wrote: > I'm now working on > > http://cplusplus.github.io/LWG/lwg-defects.html#2861 > > The new wording state is now equivalent to basic_string_view, whose > current implementation doesn't bother verifying the requirement, so > this code (which as UB) currently compiles just fine: > > #include > #include > > struct MyTraits : std::char_traits > { > typedef unsigned char char_type; > }; > > int main() > { > std::basic_string my_string; > std::basic_string_view my_string_view; > } > > So the least I could do is just - nothing. But it seems to me that we > could protect users from doing such silly things by adding a > static_assert to both basic_string and basic_string_view, the former > being equivalent to > > #if __cplusplus >=3D 201103L > static_assert(__are_same::value, > "traits_type::char_type must be equal to _CharT"); > #endif > > and the latter an unconditional > > static_assert(is_same::value, > "traits_type::char_type must be equal to _CharT"); > > Would you agree with that course of action? Not at this stage of gcc7 development. If the silly code compile fine then we risk breaking working code, and we're too close to a release to do that. We can reconsider for gcc8 (but even then, the code has undefined behaviour, so it would be a QoI choice whether to reject it or just accept it, as we do for containers where Alloc::value_type doesn't match the container's value_type).