Re: [Patch] Forward triviality in variant

[Jonathan Wakely <jwakely at redhat dot 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.