Type trait is_bool

[Vlad from Moscow]

Why is type trait is_bool absent in the Standard? Though the bool is an integral type it is a special type that differs from any other integral type. It is more convinient to use is_bool instead of std::is_same and the name is_bool is well known in some other languages. 

[Daniel Krügler]

2012/8/26 Vlad from Moscow <vlad....@mail.ru>:

I tend to agree, and a very similar case would be is_nullptr_t. I also think
that we should have is_scoped_enum.

- Daniel

[Vlad from Moscow]

воскресенье, 26 августа 2012 г., 18:08:20 UTC+4 пользователь Vlad from Moscow написал:

Why is type trait is_bool absent in the Standard? Though the bool is an integral type it is a special type that differs from any other integral type. It is more convinient to use is_bool instead of std::is_same and the name is_bool is well known in some other languages. 

 

Using a template alias as for example

 

template <typename T>
using is_bool = std::is_same<T, bool>;

has a shortcoming that the alias name does not belong to the standard namespace. 

[Daniel Krügler]

2012/8/26 Vlad from Moscow <vlad....@mail.ru>:
>

I would also think that this specification should better correspond to
the equivalent of:

template <typename T>
using is_bool = std::is_same<typename std::remove_cv<T>::type, bool>;

as it is for is_void, for example.

- Daniel

[Nikolay Ivchenkov]

On Sunday, August 26, 2012 6:18:32 PM UTC+4, Daniel Krügler wrote:

2012/8/26 Vlad from Moscow <vlad....@mail.ru>:
> Why is type trait is_bool absent in the Standard? Though the bool is an
> integral type it is a special type that differs from any other integral
> type. It is more convinient to use is_bool instead of std::is_same and the
> name is_bool is well known in some other languages.

I tend to agree, and a very similar case would be is_nullptr_t.

I can enumerate dozens of "special" types. What is the point in having such templates? We might have

    template <class T1, class T2>
        struct is_affined :
            is_same<T1 const volatile, T2 const volatile> {};
 
and use is_affined<T, void> instead of is_void<T>, is_affined<T, nullptr_t> instead of is_nullptr_t<T>, and so on.

[Johannes Schaub]

I am a complete library noob, but this sounds a lot better than having all the separate traits. I can see how "is_void" makes sense as a separate tool because "void" is a separate type category ("void types"). But from there onwards, it looks better to me to have an is_affined or something that captures all further types. 

[Vlad from Moscow]

понедельник, 27 августа 2012 г., 0:10:56 UTC+4 пользователь Nikolay Ivchenkov написал:

First of all bool is indeed a special type compared to all other types including integral types. Usually there is no any sense to perform arithmetic ooerations with the bool. If a template class is defined and a parameter of which shall be an integral type and inside the class some arithmetic is used for members of this parameter type the bool is usually excluded as an argument for such a class. 

The name is_bool is welll known in some other languages and its semantic is much clear than std::is_same. 

[Johannes Schaub]

Am 26.08.2012 22:30 schrieb "Vlad from Moscow" <vlad....@mail.ru>:
>
>
> понедельник, 27 августа 2012 г., 0:10:56 UTC+4 пользователь Nikolay Ivchenkov написал:
>>
>> On Sunday, August 26, 2012 6:18:32 PM UTC+4, Daniel Krügler wrote:
>>>
>>> 2012/8/26 Vlad from Moscow <vlad....@mail.ru>:
>>> > Why is type trait is_bool absent in the Standard?

>> I can enumerate dozens of "special" types. What is the point in having such templates? We might have

>>
>>     template <class T1, class T2>
>>         struct is_affined :
>>             is_same<T1 const volatile, T2 const volatile> {};
>>  
>> and use is_affined<T, void> instead of is_void<T>, is_affined<T, nullptr_t> instead of is_nullptr_t<T>, and so on.
>>  
>
> First of all bool is indeed a special type compared to all other types including integral types.

I would agree with this. Bool is the only integral type that cannot represent any number (not even zero and one; despite most current implementations treating it as such).

--