On Mon, Sep 17, 2012 at 10:06 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Sep 16 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
On Sun, Sep 16, 2012 at 6:27 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Tue Sep 04 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
Just to consider all alternatives, we could also do this:
CONTRACT_FUNCTION( template( typename To, typename From ) if( // used with enable_if in the declaration part is_convertible<From, To>::value, is_convertible<To, From>::value )
+1 for "if." Andrzej's "enable_if" suggestion is nice and more explicit too, but there's no syntax highlighting bonus. I'm torn.
requires( // included in the function body
The fact that this is "included in the function body" is irrelevant I think. I guess the real point you're trying to make is that it generates hard errors at acompile time when violated. That suggests something like "asserts" instead of "requires."
Then I think "check" for hard errors and "requires" for SFINAE is a good choice (requires better than if or enable_if for SFINAE I think...).
I don't see what justifies any of those conclusions. Neither "check" nor "requires" particularly implies hard errors or SFINAE. enable_if does, even if you don't know what SFINAE is.
I'll keep all the options open but I want to read N3351 before making an actual proposal. I will check with this ML before making a final decision so we can all agree on the names to use (of course any name requires, check, if, enable_if, etc is fine from an implementation prospective). BTW, I'm using requires also to express: 1. Assertion requirements. Those disable assertion compilation and checking when they are not met--no hard error. 2. Boost.Parameter predicate type requirements. (As you know well) those latter ones are unary boolean meta-functions that disable the function declaration in case they are not met--no hard error. I will also consider consistency with these other usages of requires in proposing the name. Thanks. --Lorenzo