[cfe-dev] intrinsics documentation?

[Howard Hinnant]

On Oct 8, 2010, at 7:32 AM, Sebastian Redl wrote:

> On 07.10.2010 20:43, Howard Hinnant wrote:
>> Here's a list of intrinsics that I wish were documented but aren't.  I'd document them myself, but it would be too easy for me to make incorrect assumptions about corner cases.
>> 
>> __is_union
>> __is_class
>> __is_enum
>> __has_trivial_constructor
>> __has_nothrow_constructor
>> __has_trivial_copy
>> __has_nothrow_copy
>> __has_trivial_assign
>> __has_nothrow_assign
>> __has_trivial_destructor
>> __has_virtual_destructor
>> __is_pod
>> __is_convertible_to
>> __is_base_of
>> 
>> And perhaps I've missed some, I'm not sure.  For example I'd love to also see:
>> 
>> __underlying_type
>> __is_trivial
>> __is_trivially_copyable
>> __is_standard_layout
>> __is_literal_type
>> __is_nothrow_constructible
>> __is_trivially_constructible
>> __is_nothrow_assignable
>> __is_trivially_assignable
>> __is_destructible
>> __is_nothrow_destructible
>> __is_trivally_destructible
>> 
> The intention of all type trait intrinsics is to directly implement the 
> corresponding standard library type trait. Any divergence is a bug in 
> our implementation. Do any of these traits not have a corresponding type 
> trait? If so, then another consideration is whether we actually want 
> that intrinsic.

I've put up a design doc at:

http://libcxx.llvm.org/type_traits_design.html

This lists the traits we need for the std::lib, and compares it with the traits clang currently supplies.  Some of the supplied traits are absolutely necessary, some are useful, others are unneeded, and some desperately needed traits are missing.

The missing traits are by no means the fault of the clang dev team.  This list of traits reflects a traits-adjustment paper just voted in last week:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html

-Howard