When using __attribute__((enable_if(...))) with a condition that may be ill-formed, you cannot use a requires clause to constrain the function to only be considered in the well-formed cases, because apparently the enable_if condition is considered first.
The workaround is to use SFINAE instead, which is ugly.
IMO, enable_if should be considered after constraint satisfaction (like with SFINAE), not before. Optionally, if the condition for enable_if is ill-formed the overload could just be considered to be not enabled, but that might be a bridge too far.
When using `__attribute__((enable_if(...)))` with a condition that may be ill-formed, you cannot use a `requires` clause to constrain the function to only be considered in the well-formed cases, because apparently the `enable_if` condition is considered first.
The workaround is to use SFINAE instead, which is ugly.
Sample code: https://godbolt.org/z/x3MjWv1ET
IMO, enable_if should be considered after constraint satisfaction (like with SFINAE), not before. Optionally, if the condition for `enable_if` is ill-formed the overload could just be considered to be not enabled, but that might be a bridge too far.
When using
__attribute__((enable_if(...)))
with a condition that may be ill-formed, you cannot use arequires
clause to constrain the function to only be considered in the well-formed cases, because apparently theenable_if
condition is considered first.The workaround is to use SFINAE instead, which is ugly.
Sample code: https://godbolt.org/z/x3MjWv1ET
IMO, enable_if should be considered after constraint satisfaction (like with SFINAE), not before. Optionally, if the condition for
enable_if
is ill-formed the overload could just be considered to be not enabled, but that might be a bridge too far.