patch: new attribute enable_if
richard at metafoo.co.uk
Mon Sep 23 16:19:30 PDT 2013
On Sun, Sep 22, 2013 at 3:01 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Chandler Carruth wrote:
>> On Sun, Sep 22, 2013 at 3:24 AM, Nick Lewycky <nicholas at mxc.ca
>> <mailto:nicholas at mxc.ca>> 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.
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits