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

Subject: Re: [boost] [contract] static_assert in contracts or not?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-18 02:35:25

Le 18/09/12 06:14, Lorenzo Caminiti a écrit :
> 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 ;)
I'm referring to traits included in the standard. See 20.9.4.3 Type 
properties [meta.unary.prop] C++ International Standard
>
>> In C++11
>> there are some traits as has_copy_constructor,
>> has_trivial_copy_constructtor, ...
> True.
Sorry, the names are is_copy_constructible, is trivially_copyable, ...
>
>>> 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
I don't know if this this is a valid argument. I would say that we need 
"enable_if" to avoid instantiation that will result on compiler error 
and static assertions to report bad instantiations at compile time.

>   (if Boost.Contract will
> ever support both, I'll have to document why that is the case).
I guess the preceding is just a good justification.
>
> 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.
>
>
Yeah, this will be great. I think this could be done before including 
enable_if as the user can take advantage of these traits independently 
of whether the class's user uses Boost.Contract or not. I you want I 
could help proposing the addition of these traits in Boost.TypeTraits so 
that they can be specialized by the user and by Boost.Contract in 
particular.

Best,
Vicente