From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-454964-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 97977 invoked by alias); 1 Jun 2017 16:03:32 -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 97459 invoked by uid 89); 1 Jun 2017 16:03:27 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:815
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; Thu, 01 Jun 2017 16:03:25 +0000
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id 16FE319C62F;	Thu,  1 Jun 2017 16:03:28 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 16FE319C62F
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jwakely@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 16FE319C62F
Received: from localhost (unknown [10.33.36.83])	by smtp.corp.redhat.com (Postfix) with ESMTP id BD52B5DC18;	Thu,  1 Jun 2017 16:03:27 +0000 (UTC)
Date: Thu, 01 Jun 2017 16:03:00 -0000
From: Jonathan Wakely <jwakely@redhat.com>
To: Ville Voutilainen <ville.voutilainen@gmail.com>
Cc: Tim Shen <timshen@google.com>, libstdc++ <libstdc++@gcc.gnu.org>,	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch] Forward triviality in variant
Message-ID: <20170601160327.GW12306@redhat.com>
References: <CAG4ZjNnp4DQXpBEs7yu-MCrfUGfk+3x=KkPZqJiQ5WWt3awnvg@mail.gmail.com> <CAG4ZjNm1vWNAS8qytZaFV7DDdS3=fONkqjgUWUA4cY0ppsuaNg@mail.gmail.com> <20170601151302.GA10443@redhat.com> <CAFk2RUZX+UcWg68yT-TXZj6sXcExzvHB4x9xg4bkN_eZvQb91Q@mail.gmail.com> <20170601152913.GC10443@redhat.com> <CAFk2RUYBpC-PQaR9XWrjswZBoPDj0cCYXS2mfbpuUz0mSU5a9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CAFk2RUYBpC-PQaR9XWrjswZBoPDj0cCYXS2mfbpuUz0mSU5a9Q@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.8.0 (2017-02-23)
X-SW-Source: 2017-06/txt/msg00059.txt.bz2

On 01/06/17 18:43 +0300, Ville Voutilainen wrote:
>On 1 June 2017 at 18:29, Jonathan Wakely <jwakely@redhat.com> wrote:
>>> They all seem to be shortcuts for something::value, so it seems to me
>>> logical to have
>>> them all be _v.
>>
>>
>> The _v suffixes in the standard are there to distinguish std::foo from
>> std::foo_v, but we don't have that problem.
>
>Wouldn't necessarily hurt to follow the same naming convention idea as
>the standard, but sure, we
>don't have that problem, agreed.

It's not consistent in the standard:

- numeric_limits<T>::is_specialized
- std::chrono::system_clock::is_steady
- std::atomic<T>::is_always_lock_free

And that's OK, because it would be a silly rule that said all boolean
constants should end in _v, it would just be noise.