Dominique Devienne wrote:
From reading the Boost ML, it seems that one of the major difference between the "competing" modern meta-programming libraries is around SFINAE [1], yet I found a single mention in the doc for a subtle use of mp_defer. For non-experts like me, it might be useful to highlight more of the design rational for going with "simpler and eager-by-default" design (if I got that right) while still allowing SFINAE via mp_defer, versus other SFINAE-first approaches?
mp_defer is not an alternative to SFINAE-friendly algorithms. It's a tool that can be used to implement SFINAE-friendly traits. The standard library, for example, occasionally says "this trait should have a nested type equivalent to that if valid, otherwise should have no nested type." This is what mp_defer implements; given a SFINAE-friendly template alias, it gives you the trait. Providing mp_defer is not a replacement to algorithms being SFINAE-friendly. Ideally, they should be, although to what degree is still a subject of active discussion. I haven't made them so because it's kind of hard; compilers, even latest ones, often do not implement SFINAE properly in corner cases, to say nothing about their earlier versions. Proper, all the way, SFINAE friendliness is quite a but of work, and is often unnecessary in practice. For example, mp_transform<F, L1, L2> can fail if 1. L1 or L2 is not a list; 2. L1 and L2 are not of the same size; 3. F<T1, T2> for some T1/T2 from L1/L2 fails. I had implemented (1) in my original iteration, now I'm at (2), but haven't got (3). This is not a design decision; it's just what the implementation currently does. It's also not a property of the eager by default design; eager by default can still SFINAE.