Re: [boost] [contract] static_assert in contracts or not?

Subject: Re: [boost] [contract] static_assert in contracts or not?
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-09-18 00:14:38

On Sun, Sep 16, 2012 at 11:56 PM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> Le 17/09/12 05:26, Lorenzo Caminiti a écrit :
>
>> On Sun, Sep 16, 2012 at 6:31 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>>
>>> on Mon Sep 03 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> wrote:
>>>
>>>> I do not know if Boost.ConceptCheck offers the capability of verifying
>>>> any
>>>> boolean predicate.
>>>
>>> Sure; even if the concept isn't already in the library, you can easily
>>> write it.
>>
>> So if we can program a static boolean predicate then we can program a
>> ConceptCheck concept that will statically assert it and make it fail
>> at compile-time. I guess however that the opposite is not true. There
>> are conditions that can be programmed to generate a hard compiler
>> failure (e.g., using ConceptCheck) but we cannot create a boolean
>> meta-function for them (e.g., to use enable-if and/or SFINAE-like
>> concepts).
>>
>> For example we can program CopyConstructible but we cannot program
>> has_copy_constructor--am I correct? Is that true with C++11 expression
>> SFINAE as well?
>
> This depends on the c++ version as some traits need compiler help.

Compiler help outside the standard (either C++03 or C++11) doesn't count ;)

> In C++11
> there are some traits as has_copy_constructor,
> has_trivial_copy_constructtor, ...

True.

>> If that is the case, there can be type requirements that we can only
>> program using hard-failing-concepts (ConceptCheck concepts within
>> Contract's check clause) but not using SFINAE-concepts (possible
>> future Boost.Contract's requires clause).
>>
>>
> You are surely right, but it is less evident for c++11.

True.

> Do you have an
> example?

Not on top of my head, I'll probably have examples after studying
N3351. In any case, this is just an argument to have /both/
hard-error-concepts and enable-if-concepts (if Boost.Contract will
ever support both, I'll have to document why that is the case).

BTW, now that I'm thinking about it, if you use Boost.Contract to
declare a class/function, I /might/ be able to expand some extra code
that will support compile-time trait inspection... For example,
has_copy_constructor /could/ be made to work for a constructor
declared using CONTRACT_CONSTRUCTOR even on C++03 and without extra
compiler help... I'll look into this if/when extending Boost.Contract
to support N3351-like concepts.

Thanks,
--Lorenzo