RFR: JDK-8299386: Refactor metaprogramming to use <type_traits>

[Kim Barrett]

On Wed, 28 Dec 2022 08:02:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Cleanup `metaprogramming/` to just use implementations from `<type_traits>` that are available in C++11 and onward.
>
> I started out intending to suggest replacing some of these changes by instead
> updating the uses of a couple that are rarely used, and getting rid of the
> associated pre-C++11 synonyms entirely. But it turns out most are rarely used,
> leading me to question this change almost in its entirety.
> 
> I think better would be a series of changes to replace uses of the synonyms
> with the corresponding element from <type_traits> and delete the synonyms.  I
> say "a series of changes" because I would prefer it not be done all in one
> changeset, for easier reviewing.
> 
> I suggest making an exception for EnableIf, because of the number of uses and
> because I'm hoping we'll be able to revise them in a better way in the not too
> distant future. Many of the uses are for function SFINAE, where the syntax is
> pretty horrible. We have the newer form of function SFINAE available (see
> ENABLE_IF), but I think in many/most cases even better would be to use C++17
> constexpr if. That's why I haven't proposed rewriting any of them using
> ENABLE_IF. I'm hopeful that using C++17 isn't too far away, now that there
> seems to be a compiler available for the aix-ppc port.

> @kimbarrett Though once its just those three files, it begs the question of whether having `metaprogramming/` itself is necessary. Maybe it makes more sense to have a single header under `utilities/`?

I'm hopeful that we'll soon have C++17, which will similarly remove the need for logical.hpp.  There aren't many uses of those metafunctions either.  So I think there's no point in moving it.

I've already described what I think should be done with EnableIf, so again no point in moving it.

PrimitiveConversions::cast<T> => std::bit_cast<T>, but that's in C++20, so likely still some way out for us.
And the PrimitiveConversions::Translate is our own thing.
So it might make sense to move that someday, but I don't see any need to hurry.

-------------

PR: https://git.openjdk.org/jdk/pull/11794