Back to home page

EIC code displayed by LXR

 
 

    


File indexing completed on 2025-12-15 09:53:03

0001 /*!
0002 @file
0003 Forward declares `boost::hana::eval_if`.
0004 
0005 Copyright Louis Dionne 2013-2022
0006 Distributed under the Boost Software License, Version 1.0.
0007 (See accompanying file LICENSE.md or copy at http://boost.org/LICENSE_1_0.txt)
0008  */
0009 
0010 #ifndef BOOST_HANA_FWD_EVAL_IF_HPP
0011 #define BOOST_HANA_FWD_EVAL_IF_HPP
0012 
0013 #include <boost/hana/config.hpp>
0014 #include <boost/hana/core/when.hpp>
0015 
0016 
0017 namespace boost { namespace hana {
0018     //! Conditionally execute one of two branches based on a condition.
0019     //! @ingroup group-Logical
0020     //!
0021     //! Given a condition and two branches in the form of lambdas or
0022     //! `hana::lazy`s, `eval_if` will evaluate the branch selected by the
0023     //! condition with `eval` and return the result. The exact requirements
0024     //! for what the branches may be are the same requirements as those for
0025     //! the `eval` function.
0026     //!
0027     //!
0028     //! Deferring compile-time evaluation inside `eval_if`
0029     //! --------------------------------------------------
0030     //! By passing a unary callable to `eval_if`, it is possible to defer
0031     //! the compile-time evaluation of selected expressions inside the
0032     //! lambda. This is useful when instantiating a branch would trigger
0033     //! a compile-time error; we only want the branch to be instantiated
0034     //! when that branch is selected. Here's how it can be achieved.
0035     //!
0036     //! For simplicity, we'll use a unary lambda as our unary callable.
0037     //! Our lambda must accept a parameter (usually called `_`), which
0038     //! can be used to defer the compile-time evaluation of expressions
0039     //! as required. For example,
0040     //! @code
0041     //!     template <typename N>
0042     //!     auto fact(N n) {
0043     //!         return hana::eval_if(n == hana::int_c<0>,
0044     //!             [] { return hana::int_c<1>; },
0045     //!             [=](auto _) { return n * fact(_(n) - hana::int_c<1>); }
0046     //!         );
0047     //!     }
0048     //! @endcode
0049     //!
0050     //! What happens here is that `eval_if` will call `eval` on the selected
0051     //! branch. In turn, `eval` will call the selected branch either with
0052     //! nothing -- for the _then_ branch -- or with `hana::id` -- for the
0053     //! _else_ branch. Hence, `_(x)` is always the same as `x`, but the
0054     //! compiler can't tell until the lambda has been called! Hence, the
0055     //! compiler has to wait before it instantiates the body of the lambda
0056     //! and no infinite recursion happens. However, this trick to delay the
0057     //! instantiation of the lambda's body can only be used when the condition
0058     //! is known at compile-time, because otherwise both branches have to be
0059     //! instantiated inside the `eval_if` anyway.
0060     //!
0061     //! There are several caveats to note with this approach to lazy branching.
0062     //! First, because we're using lambdas, it means that the function's
0063     //! result can't be used in a constant expression. This is a limitation
0064     //! of the current language.
0065     //!
0066     //! The second caveat is that compilers currently have several bugs
0067     //! regarding deeply nested lambdas with captures. So you always risk
0068     //! crashing the compiler, but this is a question of time before it is
0069     //! not a problem anymore.
0070     //!
0071     //! Finally, it means that conditionals can't be written directly inside
0072     //! unevaluated contexts. The reason is that a lambda can't appear in an
0073     //! unevaluated context, for example in `decltype`. One way to workaround
0074     //! this is to completely lift your type computations into variable
0075     //! templates instead. For example, instead of writing
0076     //! @code
0077     //!     template <typename T>
0078     //!     struct pointerize : decltype(
0079     //!         hana::eval_if(hana::traits::is_pointer(hana::type_c<T>),
0080     //!             [] { return hana::type_c<T>; },
0081     //!             [](auto _) { return _(hana::traits::add_pointer)(hana::type_c<T>); }
0082     //!         ))
0083     //!     { };
0084     //! @endcode
0085     //!
0086     //! you could instead write
0087     //!
0088     //! @code
0089     //!     template <typename T>
0090     //!     auto pointerize_impl(T t) {
0091     //!         return hana::eval_if(hana::traits::is_pointer(t),
0092     //!             [] { return hana::type_c<T>; },
0093     //!             [](auto _) { return _(hana::traits::add_pointer)(hana::type_c<T>); }
0094     //!         );
0095     //!     }
0096     //!
0097     //!     template <typename T>
0098     //!     using pointerize = decltype(pointerize_impl(hana::type_c<T>));
0099     //! @endcode
0100     //!
0101     //! > __Note__: This example would actually be implemented more easily
0102     //! > with partial specializations, but my bag of good examples is empty
0103     //! > at the time of writing this.
0104     //!
0105     //! Now, this hoop-jumping only has to be done in one place, because
0106     //! you should use normal function notation everywhere else in your
0107     //! metaprogram to perform type computations. So the syntactic
0108     //! cost is amortized over the whole program.
0109     //!
0110     //! Another way to work around this limitation of the language would be
0111     //! to use `hana::lazy` for the branches. However, this is only suitable
0112     //! when the branches are not too complicated. With `hana::lazy`, you
0113     //! could write the previous example as
0114     //! @code
0115     //!     template <typename T>
0116     //!     struct pointerize : decltype(
0117     //!         hana::eval_if(hana::traits::is_pointer(hana::type_c<T>),
0118     //!             hana::make_lazy(hana::type_c<T>),
0119     //!             hana::make_lazy(hana::traits::add_pointer)(hana::type_c<T>)
0120     //!         ))
0121     //!     { };
0122     //! @endcode
0123     //!
0124     //!
0125     //! @param cond
0126     //! The condition determining which of the two branches is selected.
0127     //!
0128     //! @param then
0129     //! An expression called as `eval(then)` if `cond` is true-valued.
0130     //!
0131     //! @param else_
0132     //! A function called as `eval(else_)` if `cond` is false-valued.
0133     //!
0134     //!
0135     //! Example
0136     //! -------
0137     //! @include example/eval_if.cpp
0138 #ifdef BOOST_HANA_DOXYGEN_INVOKED
0139     constexpr auto eval_if = [](auto&& cond, auto&& then, auto&& else_) -> decltype(auto) {
0140         return tag-dispatched;
0141     };
0142 #else
0143     template <typename L, typename = void>
0144     struct eval_if_impl : eval_if_impl<L, when<true>> { };
0145 
0146     struct eval_if_t {
0147         template <typename Cond, typename Then, typename Else>
0148         constexpr decltype(auto) operator()(Cond&& cond, Then&& then, Else&& else_) const;
0149     };
0150 
0151     BOOST_HANA_INLINE_VARIABLE constexpr eval_if_t eval_if{};
0152 #endif
0153 }} // end namespace boost::hana
0154 
0155 #endif // !BOOST_HANA_FWD_EVAL_IF_HPP