From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-192736-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 73294 invoked by alias); 12 Mar 2017 13:21:43 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 73282 invoked by uid 89); 12 Mar 2017 13:21:42 -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=chart, protect
X-HELO: mail-wr0-f174.google.com
Received: from mail-wr0-f174.google.com (HELO mail-wr0-f174.google.com) (209.85.128.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 12 Mar 2017 13:21:40 +0000
Received: by mail-wr0-f174.google.com with SMTP id g10so89072542wrg.2        for <gcc@gcc.gnu.org>; Sun, 12 Mar 2017 06:21:41 -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:from:date:message-id:subject:to;        bh=AJRrOC3CBstFp7ynNls9MDoHx8pkctvx9rS5JfSrzF0=;        b=YK9w+aoPfygEOS8fEDtW72/rsRTGU6Dx06xbpd3c4xVpikFMwxEvzIlqfdGbOuwSNm         p9ddC0RXKChTrJoL65i9FJmokOx8CVr6ziNNVCYoJ3TxBfvTmWDXnl2sOIsHXTYQbhwD         k8GGm2zg7ckXqJ63xLFrKvTQtXgPKfzFZK3ppVh0aP1jyP5BY1U+3C3NfXPSfp8hV82a         8k2o5syR+xqjRM5AeK81/be8ch2+rv1h0LcFiHmNwgOXxiO+akXDxHAYSXGw9nGG5JlM         YIlTnK/fBZt18ohaHOCLcZKfOQ+euZ5j8BxOU1+Y5SmdhOo+hjaskEN4H+trgXDfnKnx         h1PA==
X-Gm-Message-State: AMke39lGhFOI3JRlFhlUCN/DZvzPHf//q64EN7zHvjmx/7crh90tMJAPil2UlebNFP+qjDifnt4pq7V97Hn4Iw==
X-Received: by 10.223.136.82 with SMTP id e18mr23861352wre.28.1489324899341; Sun, 12 Mar 2017 06:21:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.47.211 with HTTP; Sun, 12 Mar 2017 06:21:38 -0700 (PDT)
From: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Sun, 12 Mar 2017 13:21:00 -0000
Message-ID: <CAGNvRgDeqGG=39HVhs6-7mzLPxdhHGgBxySnjWEwT6O-wKUXYQ@mail.gmail.com>
Subject: Design question LWG 2861: basic_string should require that charT match traits::char_type
To: GCC <gcc@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2017-03/txt/msg00044.txt.bz2

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 <string>
#include <string_view>

struct MyTraits : std::char_traits<char>
{
  typedef unsigned char char_type;
};

int main()
{
  std::basic_string<char, MyTraits> my_string;
  std::basic_string_view<char, MyTraits> 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 >= 201103L
      static_assert(__are_same<value_type, _CharT>::value,
                    "traits_type::char_type must be equal to _CharT");
#endif

and the latter an unconditional

      static_assert(is_same<typename _Traits::char_type, _CharT>::value,
                    "traits_type::char_type must be equal to _CharT");

Would you agree with that course of action?

Thanks,

- Daniel