[lmi] std::identity unavailable in clang libc++

[Vadim Zeitlin]

 Hello,

 Unfortunately the perfectly innocent changes of 28955d101 (Refactor for
flexibility, 2021-07-03) broke clang build due to lack of std::identity in
its standard library, see

https://github.com/let-me-illustrate/lmi/runs/2985604779?check_suite_focus=true

 The compiler currently used for the clang builds is clang 11, but this
metafunction is still not implemented in clang 12 neither, so upgrading it
wouldn't help. Testing for __cpp_lib_type_identity would help to check
whether it's available or not, but this is just part of the solution
because we'd still need to do something to allow lmi_root() declaration to
compile.

 I see 2 possibilities here:

1. Define and use lmi_identity.
 (a) Either just define it trivially as shown in the working paper for
     std::identity itself: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0887r0.pdf
 (b) Or define it like this unless __cpp_lib_type_identity is defined, in
     which case alias it to std::identity itself.

2. Define std::identity in case __cpp_lib_type_identity is not defined.

 The obvious problem of (2) is that we are not allowed to do this, but OTOH
I can't see what problems could this ever cause this in practice -- and the
code doing it, inside "#ifndef __cpp_lib_type_identity", wouldn't ever be
used for production builds using gcc anyhow. So personally I'd rather do
(2) and keep lmi_root() itself unchanged. Would you agree with such hack?

 Also, in either case, where do you think this should be done? Doing it in
zero.hpp itself doesn't make much sense as it's not specific to it at all,
but neither does doing it in any other lmi header included from it
(null_stream.hpp or round_to.hpp), so it would seem that it needs to be
done either in config.hpp or in a new identity.hpp. Neither is perfect:
this metafunction is used pretty rarely, so defining it for everybody in
config.hpp is not ideal (this would pull in <functional>), and creating a
new header for something trivial like this seems like a waste too. What
would be your preference here?

 To summarize, the solution(s) is/are quite trivial, but I just don't know
which one would be the least distasteful for you, so I'd like to ask you to
make this choice -- and then I can implement it (of course, so could you,
if you'd prefer). But I'd like to solve it in some way, as clang/libc++
builds are IMO quite useful to have and this problem is hardly critical
enough to make us abandon them just because of it.

 Thanks in advance,
VZ

pgp_r7nfOP17f.pgp
Description: PGP signature