template <ValueType charT, class traits>
class basic_string 
{
    static_assert( tr1::is_pod<charT>::value,
                   "Template argument charT must be a POD type in class template basic_string" );
            // ...
};

1.1   Alternatives

Imagine for a moment that static invariant was allowed to appear in

• namespace scope
• class scope
• block scope

Then the two proposals would be completely overlapping.

What is left is that Contract Programming still has extra syntax for static assertions inside eg. preconditions. It seems there is yet a proposal that might have an influence on this mechanism:

• Generalized Constant Expressions

The above paper introduces the highly desirable notion of constant-valued functions such that all inline functions recursively defined only in terms of constants yield a compile-time constant.

Given such a capability in the compiler, it would make sense to demand constant-valued pre- and postconditions to be evaluated at compile-time. This would remove the syntactic irregularity found in

template< unsigned Size > 
struct array
{
    template< unsigned N >
    T& at()
    precondition
    {
        static N < Size;
    }

which now is

template< unsigned N >
T& at()
precondition
{
    N < Size;
}

The good consequence is of course that a user cannot forget to put the static keyword there---it just works as we would like it to. (Remark: this is exactly what we have done in n1866.)

2.1   Concept notation

The particular notation used to define a concept greatly affects the aesthetics and/or possibility of specifying contracts on Concepts.

Basically two ways of defining concepts are being proposed:

• pseudo-signatures, and
• usage patterns.

In the former syntax, we could define a concept as follows:

template<typeid T>
concept EqualityComparable 
{
    bool operator==(T a, T b);
    bool operator!=(T a, T b);
};  

It is quite easy and natural to add contracts to this definition:

template<typeid T>
concept EqualityComparable 
{
    bool operator==(T a, T b)
        postcondition( result ) { result == !( a != b ); }

    bool operator!=(T a, T b)
        postcondition( result ) { result == !( a == b ); }
};  

Remark: there is no infinite recursion problems here since postconditions do not check contracts.

In the spirit of usage patterns, we would write the concept as:

concept EqualityComparable< class T > 
{
    T a;
    T b;
    bool( a == b );
    bool( a == b );
};  

When we try to put contracts into this definition, it looks somewhat different:

concept EqualityComparable< class T > 
{
    T a;
    T b;
    bool( a == b )
        postcondition( result ) { result == !( a != b ); }
        
    bool( a == b )
        postcondition( result ) { result == !( a == b ); }
};  

This might not look too bad, but now consider

concept RandomAccessContainer< class T >
{
    T t;
    const T u;

    T::size_type s = u.size()   
        postcondition( result ) { if( u.empty() ) result == 0; }

    T::value_type& v = t[5]
        precondition { /* how do we refer to the argument here??? */ }              
};

Thus the usage pattern approach does not mix well with contract programming.

2.2   Concept assertions

This section discusses potential reuse of keywords.

In the Indiana proposal, the keyword require is used to make an assertion about nested types:

template< typeid X >
concept Container 
{
    ...
    require typename X::iterator;
    require InputIterator<X::iterator>;
    ...
};

It might be ok to reuse static invariant (or simply invariant) here:

template< typeid X >
concept Container 
{
    ...
    static invariant
    {
        typename X::iterator;
        InputIterator<X::iterator>;
    }    
    ...
};

Both proposals define ways to explicitly state that a UDT adheres to a particular concept. In the Texas proposal the keyword static_assert is used as follows:

static_assert Forward_iterator<Ptr_to_int>;

where Forward_iterator<Ptr_to_int> can simply be thought of a predicate. It might not be too bad to say

static invariant
{
    Forward_iterator<Ptr_to_int>;
}

instead. static invariant has a natural block structure that will make it easier to specify several predicates.