Re: [Patch] Forward triviality in variant

[Ville Voutilainen <ville.voutilainen@gmail.com>]

On 1 June 2017 at 19:03, Jonathan Wakely <jwakely@redhat.com> wrote:
> 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.


But I didn't suggest such a rule, merely that if we are doing with a
trait-like variable
that shortcuts a ::value, then we could entertain using _v.