On Sun, Sep 22, 2013 at 3:01 PM, Nick Lewycky <[email protected]> wrote:
> Chandler Carruth wrote: > >> On Sun, Sep 22, 2013 at 3:24 AM, Nick Lewycky <[email protected] >> <mailto:[email protected]>> 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 constraints/std::enable_if. > 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 > [email protected] > http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-commits<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
