Re: [boost] Request for endorsements for mp11

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.