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

[Greg Chicares]

On 2021-07-05 13:02, Vadim Zeitlin wrote:
> 
>  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.

There are two "identity" things:
  - std::identity      // <functional>   [func.identity]
  - std::type_identity // <type_traits>  [meta.trans.other]
AFAICT __cpp_lib_type_identity tests for the latter, but we want the former,
which doesn't seem to have a feature-test macro...or is one of the following
suitable?

  __cpp_lib_constexpr_functional
because it uses 'constexpr' in [func.identity]

  __cpp_lib_transparent_operators
because it uses 'is_transparent' in [func.identity]

Or maybe both should be used; or maybe even both together aren't enough.

>  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

Doesn't that paper pertain to std::type_identity?

Instead, see this very recent commit:
  [master 4d8cb2292] Work around a clang issue

>  (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.

There doesn't seem to exist a feature-test macro for this.

>  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?

I'd have preferred that, yes. What I did is arguably more hackish.

>  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>),

Agreed.

> and creating a
> new header for something trivial like this seems like a waste too. What
> would be your preference here?

I wanted to put it someplace like
  math_functions.hpp [but it's not a math function]
  stl_extensions.hpp [but it's not STL]
  miscellany.hpp     [which is already too...miscellaneous]
but, it being a hapax legomenon, I hacked it locally, where it'll
be easy to revert.

Now let's see whether clang has std::midpoint() [commit facecf48b].