Associated functions

◆ decltype_

decltype keyword, lifted to Hana.

Deprecated:

The semantics of decltype_ can be confusing, and hana::typeid_ should be preferred instead. decltype_ may be removed in the next major version of the library.

decltype_ is somewhat equivalent to decltype in that it returns the type of an object, except it returns it as a hana::type which is a first-class citizen of Hana instead of a raw C++ type. Specifically, given an object x , decltype_ satisfies

As you can see, decltype_ will strip any reference from the object's actual type. The reason for doing so is explained below. However, any cv -qualifiers will be retained. Also, when given a hana::type , decltype_ is just the identity function. Hence, for any C++ type T ,

In conjunction with the way metafunction & al. are specified, this behavior makes it easier to interact with both types and values at the same time. However, it does make it impossible to create a type containing another type with decltype_ . In other words, it is not possible to create a type_c<decltype(type_c<T>)> with this utility, because decltype_(type_c<T>) would be just type_c<T> instead of type_c<decltype(type_c<T>)> . This use case is assumed to be rare and a hand-coded function can be used if this is needed.

The rules for template argument deduction are such that a perfect solution that always matches decltype is impossible. Hence, we have to settle on a solution that's good and and consistent enough for our needs. One case where matching decltype 's behavior is impossible is when the argument is a plain, unparenthesized variable or function parameter. In that case, decltype_ 's argument will be deduced as a reference to that variable, but decltype would have given us the actual type of that variable, without references. Also, given the current definition of metafunction & al., it would be mostly useless if decltype_ could return a reference, because it is unlikely that F expects a reference in its simplest use case:

Hence, always discarding references seems to be the least painful solution.

Returns a hana::type representing the type of a given object.

hana::typeid_ is somewhat similar to typeid in that it returns something that represents the type of an object. However, what typeid returns represent the runtime type of the object, while hana::typeid_ returns the static type of the object. Specifically, given an object x , typeid_ satisfies

As you can see, typeid_ strips any reference and cv-qualifier from the object's actual type. The reason for doing so is that it faithfully models how the language's typeid behaves with respect to reference and cv-qualifiers, and it also turns out to be the desirable behavior most of the time. Also, when given a hana::type , typeid_ is just the identity function. Hence, for any C++ type T ,

In conjunction with the way metafunction & al. are specified, this behavior makes it easier to interact with both types and values at the same time. However, it does make it impossible to create a type containing another type using typeid_ . This use case is assumed to be rare and a hand-coded function can be used if this is needed.