Subject: Re: [boost] Request for endorsements for mp11
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-22 14:04:09
Dominique Devienne wrote:
> > https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
>
> 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.