On 6/2/2015 3:42 AM, Peter Dimov wrote:
Bruno Dutra wrote:
Still, laziness and SFINAE friendliness are the properties I deem most fundamental on any metaprogramming library.
I meant to respond to these points too.
The eagerness of template aliases is an obvious problem in at least one place and that place is mp_if, where the naive mp_if
evaluates both F<T> and G<T>. But I'm not sure if there are others, under the assumption that we've no higher-order constructs. Eric Niebler's meta has an entire lazy:: namespace with deferred copies of all its constructs; continuing the general theme, I wonder whether all this is strictly needed once we jettison the lambda part.
In my experience, meta::defer (and all the stuff in meta's lazy:: namespace) is useful outside of lambdas. You want to defer computations for branches and short-circuit evaluation (if, and, or) where the branch(es) not taken would have hard errors; or for compile-time optimization, to avoid computing results you won't use. This is real, and has nothing to do with lambdas.
SFINAE friendliness can be quite a curse. It often transforms reasonably comprehensible error messages into full-scale Agatha Christie mysteries (the compiler output even being of comparable length). So I'm not convinced (at the moment) that a metaprogramming library should be SFINAE-friendly. I presently tend to lean towards the philosophy of static_assert'ing as much as possible, and leaving the primary templates undefined instead of empty.
I made Meta SFINAE-friendly on a lark and found it useful in practice. (See this thread[*] where Louis and I compared common_type implementations with Meta and Hana.) Of course you're right about mysterious errors, and I don't feel I have a good response yet. [*] http://lists.boost.org/Archives/boost/2015/03/220446.php -- Eric Niebler Boost.org http://www.boost.org