Re: [Patch] Forward triviality in variant

[Jonathan Wakely <jwakely@redhat.com>]

On 01/06/17 19:07 +0300, Ville Voutilainen wrote:
>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.

The trait describes properties of the variant. The fact those
properties are determined by something::value is an implementation
detail, not an important feature that needs to be in the name.

The implementation details should not leak into the public API of the
trait.