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

[Erik Österlund]

Hi Kim,

Looks good.

Thanks,
/Erik

On 2020-08-31 11:18, Kim Barrett wrote:
>> 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/
>
>
>