Re: [boost] [contract] toward N3351 concepts

Subject: Re: [boost] [contract] toward N3351 concepts
From: Evgeny Panasyuk (evgeny.panasyuk_at_[hidden])
Date: 2012-10-10 14:35:46

10.10.2012 12:50, Lorenzo Caminiti wrote:
> On Wed, Oct 10, 2012 at 12:57 AM, Andrzej Krzemienski
> <akrzemi1_at_[hidden]> wrote:
>>> P.S. I just have wild idea - what about axioms for function's arguments?
>>> i.e. not on types, but on values.
>>> Maybe some kind of axiomatic_assert.
>>> For instance that can be used to prevent pointers aliasing ("restrict"
>>> keyword in C99):
>>> void* memcpy( void* dest, const void* src, size_t count )
>>> {
>>>      axiomatic_assert( do_not_overlap(dest,src,count) );
>>>      // ...
>>> }
>>>
>> Is this not the same thing as preconditions in contract programming and
>> Lorenzo's Boost.Contract library?
> I think it is

I supposed that axiomatic_asserts MUST be never checked. For instance, 
because such conditions may not be true in all cases, like in concept's 
axioms (however, there are several different opinions in this regard).

> (of course, Boost.Contract preconditions are better
> because in declarations, const-correct, etc).

I do not restrict axiomatic_assert to function's body, some kind of 
similar feature may appear in declarations too.
Main idea is to have general mechanism to give away some portions of 
semantic, in a favour of performance - to sign a contract with 
compiler's optimizer.
Concept's axioms are applied only to types, but not to specific 
variables. While axiomatic_assert can be used to state semantic 
relations on specific set of variables.

> On this topic, I still didn't give up the desire of generating
> preconditions from axioms and checking them at run-time.

In general, do you think that C++ axioms MUST always be preserved?

Best Regards,
Evgeny