RFR: 8251274: Provide utility types for function SFINAE using extra template parameters

[Kim Barrett]

> On Aug 31, 2020, at 4:55 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> On 2020-08-28 21:46, Kim Barrett wrote:
>>> So this value SFINAE only macro for doing SFINAE using a template parameter seems like
>>> something that we can actually do without relying on any compiler bugs being fixed or
>>> refactoring the world in HotSpot (yet). And I think it is more readable than the return
>>> type SFINAE we have today (that requires extra lines for the return type, and you have
>>> to scratch your head to figure out what the actual return type is). I would say that
>>> such a value SFINAE macro is worthwhile doing, IMO.
>> This is the main point of all this, of course. As you know, I really dislike
>> the C++98 function template SFINAE syntax. So much so that I'd rather
>> delegate to class templates, as was done with the Atomic::*Impl classes. The
>> new style enabled by this C++11 feature changes everything. So I'm highly
>> motivated to reach some consensus on how we're going to use this new
>> feature.
> 
> Agreed.
> 
>> I think that macro is okay. I would be even happier with it if we had
>> variable templates for the type traits, a la C++17, so
>> 
>>   std::is_integral<T>::value => std::is_integral_v<T>
>> 
>> We could add a suite of IsIntegralV &etc variable templates. Alternatively,
>> I wonder how much trouble we might be taking on if we conditionally defined
>> them with something like
>> 
>> #if __cplusplus == 201402L
>> namespace std {
>> template<typename T> constexpr bool is_integral_v = std::is_integral<T>::value;
>> ...
>> }
>> #endif // __cplusplus
>> 
>> […]
> 
> That seems like a good idea. And yeah I really don't think that difference will matter at all.
> 
>>> I tried it in my usecase I mentioned, and I think it looks pretty good. Feels like
>>> having a nice comfortable sofa in the sewers. I think I want this nice comfortable sofa.
>>> 
>>> What do you think?
>> I had code that used the combined type/value macro and was ready to move forward
>> with that until I tried testing with Visual Studio (sigh!).  I’d prefer being able to use the
>> variable template forms of various traits, but could live without if need be.
>> 
>> If we adopt this macro, I'm inclined to just drop the proposed
>> EnableIfAnd<...> and EnableIfOr<…>.  […]
> 
> That makes sense. Using the macro and dropping the EnableIf{And | Or} sounds good to me.

OK.  Then here’s a new webrev.  (The gtest file has no changes now, but still shows up in the
webrev because of the change then revert in the patch series.)  Just a full, since there seems
little point in an incremental.

https://cr.openjdk.java.net/~kbarrett/8251274/open.01/