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

[Erik Österlund]

Hi Kim,

On 2020-08-27 10:37, Kim Barrett wrote:
>> On Aug 27, 2020, at 4:24 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>>
>> While I think having a legacy style that we are telling people not to use is unfortunate, I do understand that such a cleanup is a larger undertaking. So if the concern is that the identifier "EnableIf" is already taken today, then I think you can do what your previous example did: call the macro variant used inside of the template arguments ENABLE_IF instead, and have it take values only. Then we can transition away from using now "legacy" EnableIf gradually. And seeing as it is a macro, using capital letters is the natural name anyway.
> I think there’s a misunderstanding here.
>
> The failed (because of MSVC bugs) approach of an ENABLE_IF macro that accepts either a type
> or a constexpr value is just not on the table.
>
> What’s being proposed has zero macros; it’s all alias templates.
> I considered having macros in order to eliminate the trailing “= 0”, but that benefit didn’t seem to
> me to be worth (on it’s own) the issues that come with macros.  (And remember that I like macros.)

Thank you for the clarification.

So you said the approach of using ENABLE_IF macro that accepts either a 
type or constexpr value isn't on the table due to said compiler bugs. 
What was not and still is not clear to me is if the same bugs prevent an 
ENABLE_IF macro that accepts only a constexpr value. If that is also not 
on the table, then I see that we have a naming problem as long as the 
old legacy EnableIf is around. In other words - was the nature of the 
compiler problem that you can't use macros here at all, as opposed to 
being due to having to accept both types and values?

I would appreciate clarification on that point in the problem domain 
before thinking further about the solution domain.

Thanks,
/Erik