patch: new attribute enable_if

Richard Smith richard at
Mon Sep 23 16:19:30 PDT 2013

On Sun, Sep 22, 2013 at 3:01 PM, Nick Lewycky <nicholas at> wrote:

> Chandler Carruth wrote:
>> On Sun, Sep 22, 2013 at 3:24 AM, Nick Lewycky <nicholas at
>> <mailto:nicholas at>> wrote:
>>     The attached patch adds a new attribute named "enable_if" which
>>     takes an expression and a string. At the call site, the arguments
>>     are substituted into the enable_if expression (which is written in
>>     terms of the parameters) to determine whether this function is a
>>     viable candidate.
>> What's the motivation? The C++ committee looked at just such a construct
>> and currently is leaning in a different direction (concepts lite) so it
>> seems odd to add this as an extension to Clang at this point.
> C++ already has std::enable_if so I don't see any use for this in C++
> code. (Technically it's a little stronger than std::enable_if because it
> doesn't perform any decay and template instantiation can, but I don't
> expect anybody to ever care.) It's for C code, and C headers included in
> C++ code.

Actually, this is more powerful than what either std::enable_if or
constraints (concepts lite) provide. This attribute allows overload
resolution to depend on the *values* of function arguments (if they're
constant expressions), not just their types. You can implement
FORTIFY_SOURCE with this, for instance, and you can't implement it with

> The motivation is to provide a compiler extension that would allow C
> library authors to implement API checking rules, and more specifically the
> rules found in fortify. See the test/Sema/enable_if.c included in the patch
> for some examples.
> Nick
> ______________________________**_________________
> cfe-commits mailing list
> cfe-commits at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the cfe-commits mailing list