Re: [boost] [Review.Contract] Vicente's review

Subject: Re: [boost] [Review.Contract] Vicente's review
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-09-17 16:25:38

On Mon, Sep 17, 2012 at 10:06 AM, Dave Abrahams <dave_at_[hidden]> 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_at_[hidden]> 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