]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | /*! |
2 | @file | |
3 | Forward declares `boost::hana::Metafunction`. | |
4 | ||
b32b8144 | 5 | @copyright Louis Dionne 2013-2017 |
7c673cae FG |
6 | Distributed under the Boost Software License, Version 1.0. |
7 | (See accompanying file LICENSE.md or copy at http://boost.org/LICENSE_1_0.txt) | |
8 | */ | |
9 | ||
10 | #ifndef BOOST_HANA_FWD_CONCEPT_METAFUNCTION_HPP | |
11 | #define BOOST_HANA_FWD_CONCEPT_METAFUNCTION_HPP | |
12 | ||
13 | #include <boost/hana/config.hpp> | |
14 | ||
15 | ||
16 | BOOST_HANA_NAMESPACE_BEGIN | |
17 | //! @ingroup group-concepts | |
18 | //! @defgroup group-Metafunction Metafunction | |
19 | //! A `Metafunction` is a function that takes `hana::type`s as inputs and | |
20 | //! returns a `hana::type` as output. | |
21 | //! | |
22 | //! A `Metafunction` is an object satisfying the [FunctionObject][1] | |
23 | //! concept, but with additional requirements. First, it must be possible | |
24 | //! to apply a `Metafunction` to arguments whose tag is `type_tag`, and | |
25 | //! the result of such an application must be an object whose tag is also | |
26 | //! `type_tag`. Note that `hana::type` and `hana::basic_type` are the | |
27 | //! only such types. | |
28 | //! | |
29 | //! Secondly, a `Metafunction` must provide a nested `::%apply` template | |
30 | //! which allows performing the same type-level computation as is done by | |
31 | //! the call operator. In Boost.MPL parlance, a `Metafunction` `F` is | |
32 | //! hence a [MetafunctionClass][2] in addition to being a `FunctionObject`. | |
33 | //! Rigorously, the following must be satisfied by any object `f` of type | |
34 | //! `F` which is a `Metafunction`, and for arbitrary types `T...`: | |
35 | //! @code | |
36 | //! f(hana::type_c<T>...) == hana::type_c<F::apply<T...>::type> | |
37 | //! @endcode | |
38 | //! | |
39 | //! Thirdly, to ease the inter-operation of values and types, | |
40 | //! `Metafunction`s must also allow being called with arguments that | |
41 | //! are not `hana::type`s. In that case, the result is equivalent to | |
42 | //! calling the metafunction on the types of the arguments. Rigorously, | |
43 | //! this means that for arbitrary objects `x...`, | |
44 | //! @code | |
45 | //! f(x...) == f(hana::type_c<decltype(x)>...) | |
46 | //! @endcode | |
47 | //! | |
48 | //! | |
49 | //! Minimal complete definition | |
50 | //! --------------------------- | |
51 | //! The `Metafunction` concept does not have a minimal complete definition | |
52 | //! in terms of tag-dispatched methods. Instead, the syntactic requirements | |
53 | //! documented above should be satisfied, and the `Metafunction` struct | |
54 | //! should be specialized explicitly in Hana's namespace. | |
55 | //! | |
56 | //! | |
57 | //! Concrete models | |
58 | //! --------------- | |
59 | //! `hana::metafunction`, `hana::metafunction_class`, `hana::template_` | |
60 | //! | |
61 | //! | |
62 | //! Rationale: Why aren't `Metafunction`s `Comparable`? | |
63 | //! --------------------------------------------------- | |
64 | //! When seeing `hana::template_`, a question that naturally arises is | |
65 | //! whether `Metafunction`s should be made `Comparable`. Indeed, it | |
66 | //! would seem to make sense to compare two templates `F` and `G` with | |
67 | //! `template_<F> == template_<G>`. However, in the case where `F` and/or | |
68 | //! `G` are alias templates, it makes sense to talk about two types of | |
69 | //! comparisons. The first one is _shallow_ comparison, and it determines | |
70 | //! that two alias templates are equal if they are the same alias | |
71 | //! template. The second one is _deep_ comparison, and it determines | |
72 | //! that two template aliases are equal if they alias the same type for | |
73 | //! any template argument. For example, given `F` and `G` defined as | |
74 | //! @code | |
75 | //! template <typename T> | |
76 | //! using F = void; | |
77 | //! | |
78 | //! template <typename T> | |
79 | //! using G = void; | |
80 | //! @endcode | |
81 | //! | |
82 | //! shallow comparison would determine that `F` and `G` are different | |
83 | //! because they are two different template aliases, while deep comparison | |
84 | //! would determine that `F` and `G` are equal because they always | |
85 | //! expand to the same type, `void`. Unfortunately, deep comparison is | |
86 | //! impossible to implement because one would have to check `F` and `G` | |
87 | //! on all possible types. On the other hand, shallow comparison is not | |
88 | //! satisfactory because `Metafunction`s are nothing but functions on | |
89 | //! `type`s, and the equality of two functions is normally defined with | |
90 | //! deep comparison. Hence, we adopt a conservative stance and avoid | |
91 | //! providing comparison for `Metafunction`s. | |
92 | //! | |
92f5a8d4 | 93 | //! [1]: http://en.cppreference.com/w/cpp/named_req/FunctionObject |
7c673cae FG |
94 | //! [2]: http://www.boost.org/doc/libs/release/libs/mpl/doc/refmanual/metafunction-class.html |
95 | template <typename F> | |
96 | struct Metafunction; | |
97 | BOOST_HANA_NAMESPACE_END | |
98 | ||
99 | #endif // !BOOST_HANA_FWD_CONCEPT_METAFUNCTION_HPP |