63e88f80
 Hu Chunming
提交三方库
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
/*!
@file
Forward declares `boost::hana::unpack`.
Copyright Louis Dionne 2013-2022
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE.md or copy at http://boost.org/LICENSE_1_0.txt)
*/
#ifndef BOOST_HANA_FWD_UNPACK_HPP
#define BOOST_HANA_FWD_UNPACK_HPP
#include <boost/hana/config.hpp>
#include <boost/hana/core/when.hpp>
namespace boost { namespace hana {
//! Invoke a function with the elements of a Foldable as arguments.
//! @ingroup group-Foldable
//!
//! Given a function and a foldable structure whose length can be known at
//! compile-time, `unpack` invokes the function with the contents of that
//! structure. In other words, `unpack(xs, f)` is equivalent to `f(x...)`,
//! where `x...` are the elements of the structure. The length of the
//! structure must be known at compile-time, because the version of `f`'s
//! `operator()` that will be compiled depends on the number of arguments
//! it is called with, which has to be known at compile-time.
//!
//! To create a function that accepts a foldable instead of variadic
//! arguments, see `fuse` instead.
//!
//!
//! @param xs
//! The structure to expand into the function.
//!
//! @param f
//! A function to be invoked as `f(x...)`, where `x...` are the elements
//! of the structure as-if they had been linearized with `to<tuple_tag>`.
//!
//!
//! Example
//! -------
//! @include example/unpack.cpp
//!
//!
//! Rationale: `unpack`'s name and parameter order
//! ----------------------------------------------
//! It has been suggested a couple of times that `unpack` be called
//! `apply` instead, and that the parameter order be reversed to match
//! that of the [proposed std::apply function][1]. However, the name
//! `apply` is already used to denote normal function application, an use
//! which is consistent with the Boost MPL library and with the rest of
//! the world, especially the functional programming community.
//! Furthermore, the author of this library considers the proposed
//! `std::apply` to have both an unfortunate name and an unfortunate
//! parameter order. Indeed, taking the function as the first argument
//! means that using `std::apply` with a lambda function looks like
//! @code
//! std::apply([](auto ...args) {
//! use(args...);
//! }, tuple);
//! @endcode
//!
//! which is undeniably ugly because of the trailing `, tuple)` part
//! on the last line. On the other hand, taking the function as a
//! second argument allows one to write
//! @code
//! hana::unpack(tuple, [](auto ...args) {
//! use(args...);
//! });
//! @endcode
//!
//! which looks much nicer. Because of these observations, the author
//! of this library feels justified to use `unpack` instead of `apply`,
//! and to use a sane parameter order.
//!
//! [1]: http://en.cppreference.com/w/cpp/experimental/apply
#ifdef BOOST_HANA_DOXYGEN_INVOKED
constexpr auto unpack = [](auto&& xs, auto&& f) -> decltype(auto) {
return tag-dispatched;
};
#else
template <typename T, typename = void>
struct unpack_impl : unpack_impl<T, when<true>> { };
struct unpack_t {
template <typename Xs, typename F>
constexpr decltype(auto) operator()(Xs&& xs, F&& f) const;
};
BOOST_HANA_INLINE_VARIABLE constexpr unpack_t unpack{};
#endif
}} // end namespace boost::hana
#endif // !BOOST_HANA_FWD_UNPACK_HPP
|
