They should be named respectively all_of, any_of and none_of.

Whats up @brunocodutra . You got a very nice library going here.

I was looking around and getting to know the library and techniques (since I'm a template noob :) ), so I decided to pick up metal::sort which is something I (should) understand and play with it.

I took a list of 1500 reversed unique types (char[1500], char[1499] ... ) and sorted it.
I takes around 5.5 seconds to do that in my machine (GCC 6.3).

Just for fun, I implemented quick sort. Time went to 30 seconds (and can reach recursion limit - not nice).

Anyway, I was intrigued as to some implementation choices, for example:

        template<typename x, typename y>
        struct _sort_impl<list<x, y>> {
            template<template<typename...> class expr>
            using type = if_<expr<y, x>, list<y, x>, list<x, y>>;
        };

as opposed to:

        template<typename x, typename y, template<typename...> class expr>
        struct _sort_impl<list<x, y>, expr> {
            using type = if_<expr<y, x>, list<y, x>, list<x, y>>;
        };

Why is that?
I imagined it could have something to do with performance, so I changed the code into the second version but the compilation time went down to 4.5 seconds.

eval could take a second optional argument

@klemens-morgenstern sugested introducing the topic with a simpler toy example, before discussing a more complex real world usage

The overall performance of Metal is particularly sensitive to core algorithms such as metal::join<>, which could see vast improvements if fast tracked linear recursed instead of tree-folded (edouarda/brigand#127).

Compare to Boost.MPL and show that Metal produces much better error messages

Start by discussing the reasoning behind key design choices and how Metal compares to other notable metaprogramming libraries.

Currently conditional expects numbers for its predicate parameters, but it would probably be more useful if these too were treated as optionals, since it would then be possible to pass unevaluated expressions as predicates and thus avoid complex invocations that often require quoting.

Also existing code wouldn't break, since numbers are just themselves.

slice_t<list<>, integer<0>, integer<1>> triggers a compiler error instead of yielding list<>

For consistency with the standard C++ library

Would you accept a PR that adds aliases for ::value and ::type like the modern C++ standard library provides? E.g.

metal::same_v<t1, t2>

instead of:

metal::same<t1, t2>::value

If I'm not mistaken these would be implemented with variable templates:

namespace metal {
  template<typename... Ts>
  auto same_v = same<Ts...>::value;
}

Though I believe this requires C++14 so perhaps they would only be enabled if the compilation supports at least that standard.

As pointed out by @pdimov, it would be more intuitive to implement assemble_number in the Parsing Raw Literals tutorial by folding instead of transforming.

For reference, following is a standalone working implementation of an eager left fold using fold expressions.

• Tested on Clang 3.6+ and GCC 6+

#include <type_traits>

template<typename...> using void_ = void;

template<template<typename...> class expr> struct lambda {};
template<typename...> struct list {};

template<template<typename...> class expr, typename state>
struct fold_impl {
    using type = state;
};

template<template<typename...> class expr, typename state, typename val>
fold_impl<expr, expr<state, val>> operator<<(fold_impl<expr, state>&&, fold_impl<expr, val>&&);

template<typename, typename, typename, typename = void>
struct lazy_fold {};

template<typename... vals, typename state, template<typename...> class expr> 
struct lazy_fold<list<vals...>, state, lambda<expr>,
    void_<decltype((fold_impl<expr, state>{} << ... << fold_impl<expr, vals>{}))>
> :
    decltype((fold_impl<expr, state>{} << ... << fold_impl<expr, vals>{}))
{};

template<typename seq, typename state, typename lbd> using fold = typename lazy_fold<seq, state, lbd>::type;

static_assert(std::is_same<
    fold<list<int, int*, int**, int***, int****>, list<>, lambda<list>>,
    list<list<list<list<list<list<>, int>, int*>, int**>, int***>, int****>
>{});

int main() {}

A trivial generalisation, which is consistent with metal::prepend and metal::append.

invoke_t<bind_t<lambda<std::remove_pointer_t>, _1>, just<void>*> yields just<void>* whereas void is expected

This would be consistent with std::list::splice.

Currently metal::reduce<list, lbd> invokes lbd for a single element at least once whenever list contains an odd number of elements, thus lbd is required to be both unary and binary.

Should we instead only require that it be binary?

The single hpp-file download link seems to go to a file which actually contains the GitHub HTML representation of the file, not the raw code.

Generally, apply is synonymous with invoke. MPL library uses apply to invoke a metafunction or lambda. Boost.Hana's apply works just like std::invoke.

However, your apply unpacks the elements of a list and then invokes the lambda, which I found to be surprising. It seems like unpack would be a better name and would avoid the confusion.

http://reviews.llvm.org/D15421

It was pointed out that it is not immediately obvious that detailed documentation is available behind collapsible panels.

It should be improved.

metal::conditional is great for conditionally evaluating optionals, however, due to its lazy nature, it is not as well-suited for composition as an eager conditional the likes of mpl::if_.

Also, to avoid confusion with std::conditional, metal::conditional should be renamed to metal::cond after its counterpart in lisp.

Currently we require that a typed Lambda be an instance of metal::lambda, but more generally we could treat any type that matches the following signature as a typed Lambda

template<template<typename...> class> class

@pfultz2 suggested the current requirement could be to strict

metal::reverse_t<my_list<int, int*, int**>> yields metal::list<int**, int*, int> instead of my_list<int**, int*, int>

As suggested by @eldiener, it is not immediately obvious from the User Manual that Metal is continuously attested to work on the newest version of popular compilers.

The Portability section of the User Manual should be somehow reworded to make it clear.

If the same structure as that of the MPL is used, then people could really just rename from boost/mpl/... to boost/mpl2/... in their includes. Also, one advantage of a backwards compatible MPL is the fact that one does not have to relearn new stuff. The plain directory structure of the old MPL was easy to grok and I think will be expected by users of this library. Just my 0.2.

Update CMake scripts to take into account the new standards version switches in MSVC update 3

While linear recursion works, blowing up maximum recursion depth limits is not cool.

Implement a set of benchmarks that may be run via CMake and [ab]use Travis to keep the results up to date and somehow integrated into the documentation.

While investigating the cause of timeouts on metaben.ch, I came across this (on GCC 4.9):

This causes the total test time to take over 500 s, which contributes to the timing out of metaben.ch. I would suggest fixing this, or we will have to reduce the max size of the sample used for metal on metaben.ch.

This follows up from #13.

It was suggested in #59 that it shouldn't be too difficult to support the Intel compiler, given that its compliance to the C++11 is similar to that of GCC 4.7.

Currently, lifted lambdas unnecessarily evaluate every argument prior to invocation. That wouldn't be a problem if it weren't for the fact an invocation is aborted if an unused argument is empty.

For example,

metal::invoke_t<metal::lift_t<metal::_2>, metal::nothing, metal::just<int>, metal::nothing>

should yield int, but, currently, this invocation is ill-formed due to the fact lifting metal::_1 causes the evaluation of every argument, even if it only requires evaluating the second one.

same code as the Document
`
#include <metal.hpp>

// First we need some Values
union x { char payload[10]; };
class y { public: char c; };
struct z { char c; int i; };

// ... from which we construct some Lists
using l0 = metal::list<>;
using l1 = metal::prepend<l0, x>;
using l2 = metal::append<l1, z>;
using l3 = metal::insert<l2, metal::number<1>, y>;

// retrieve their elements...
static_assert(metal::same<metal::front, x>::value, "");
static_assert(metal::same<metal::back, z>::value, ""); /// cant pass
static_assert(metal::same<metal::at<l3, metal::number<1>>, y>::value, "");

// retrieve their elements...
static_assert(metal::same<metal::front, x>::value, "");
static_assert(metal::same<metal::back, >::value, ""); /// blank can pass
static_assert(metal::same<metal::at<l3, metal::number<1>>, y>::value, "");
`

travis-ci/apt-source-safelist#156
travis-ci/apt-source-safelist#279

As suggested by @grafikrobot, migrating to Trusty would have the benefit of having sudo enabled, which would make it possible to install newer version of development packages without awaiting for them to be whitelisted by the Travis crew.

Add a section to the documentation describing some of the techniques used under the hood. It should serve as a reference for contributors, as well as a gentle introduction to template metaprogramming for the uninitiated.

These are non trivial to implement and can be very handy

The C++14 feature set is implemented to a great extent since GCC 4.8 and MSVC 14 and also in its entirety since Clang 3.4.

Since these basically match the set of currently supported compiler versions, there should be no impediment preventing the use of C++14 features commonly implemented by all those compilers and their accompanying implementations of the standard library.

Inspired by P0127R1 and as a follow up to #38, Numbers in Metal can be much simplified by making them invariant to their actual underlying integral types, which are in fact irrelevant to compile time computations.

Since it is not reasonable to bump Metal requirements to C++17 at this point, added to the fact no mainstream compiler seems to implement auto template parameters as of yet, here it should suffice to fix the underlying representation of Numbers to some reasonable integral type, say std::intmax_t or even int.

As shown by the example below, lazy proxies help reducing clutter when fancy composition is desired, the question is where to put them. One option would be within namespace metal::lazy, another would be to name them like shown below, so they could live at the root of namespace metal.

originally posted on cpplang.slack.com

using namespace metal;

template<typename... args>
using Transform = bind<lambda<transform>, args...>;

template<typename... args>
using If_ = bind<lambda<if_>, args...>;

template<typename... args>
using Invoke = bind<lambda<invoke>, args...>;

using lbd = Transform<If_<Invoke<_1, _2, _3>, _2, _3>, quote<l>>;

Given a predicate pred and unary lambdas f and g, you can then conditionally transform l with either f or g according to pred.

invoke<lbd, pred, f, g>;

It should simply forward to metal::copy_if.