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