<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />
<title>Synergies between Contract Programming, Concepts and Static Assertions</title>
<meta name="author" content="Lawrence Crowl and Thorsten Ottosen" />
<meta name="date" content="2005-08-24" />
<style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:date: $Date: 2004/01/12 02:49:54 $
:version: $Revision: 1.2 $
:copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.
*/

.first {
  margin-top: 0 }

.last {
  margin-bottom: 0 }

a.toc-backref {
  text-decoration: none ;
  color: black }

dd {
  margin-bottom: 0.5em }

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 0em 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1.title {
  text-align: center }

h2.subtitle {
  text-align: center }

hr {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee }

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.option-argument {
  font-style: italic }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

table {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.citation {
  border-left: solid thin gray ;
  padding-left: 0.5ex }

table.docinfo {
  margin: 2em 4em }

table.footnote {
  border-left: solid thin black ;
  padding-left: 0.5ex }

td, th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

th.docinfo-name, th.field-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap }

h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
  font-size: 100% }

tt {
  background-color: #eeeeee }

ul.auto-toc {
  list-style-type: none }
  
pre{
  BORDER-RIGHT: gray 1pt solid;
  PADDING-RIGHT: 2pt;
  BORDER-TOP: gray 1pt solid;
  DISPLAY: block;
  PADDING-LEFT: 2pt;
  PADDING-BOTTOM: 2pt;
  BORDER-LEFT: gray 1pt solid;
  MARGIN-RIGHT: 32pt;
  PADDING-TOP: 2pt;
  BORDER-BOTTOM: gray 1pt solid;
  FONT-FAMILY: "Courier New", Courier, mono; 
  background-color: #EEEEEE; 
}


.keyword{color: #0000FF;}
.identifier{}
.comment{font-style: italic; color: #008000;}
.special{color: #800040;}
.preprocessor{color: #3F007F;}
.string{font-style: italic; color: #666666;}
.literal{/*font-style: italic;*/ color: #000000;}

</style>
</head>
<body>
<div class="document" id="synergies-between-contract-programming-concepts-and-static-assertions">
<h1 class="title">Synergies between Contract Programming, Concepts and Static Assertions</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author:</th>
<td>Lawrence Crowl and Thorsten Ottosen</td></tr>
<tr><th class="docinfo-name">Contact:</th>
<td><a class="first reference" href="mailto:lawrence.crowl&#64;sun.com">lawrence.crowl&#64;sun.com</a> and <a class="last reference" href="mailto:nesotto&#64;cs.aau.dk">nesotto&#64;cs.aau.dk</a></td></tr>
<tr class="field"><th class="docinfo-name">Organizations:</th><td class="field-body">Sun Microsystems and Dezide Aps</td>
</tr>
<tr><th class="docinfo-name">Date:</th>
<td>2005-08-24</td></tr>
<tr class="field"><th class="docinfo-name">Number:</th><td class="field-body">WG21/N1867 and  J16/05-0127</td>
</tr>
<tr class="field"><th class="docinfo-name">Working Group:</th><td class="field-body">Evolution</td>
</tr>
</tbody>
</table>
<div class="abstract topic">
<p class="topic-title first">Abstract</p>
<p>This paper explores the synergies between Contract Programming,
Concepts and Static Assertions. 
Contract Programming and Concepts seem to be quite
orthogonal and complement each other whereas Contract 
Programming and Static Assertions are overlapping proposals.</p>
</div>
<div class="contents topic" id="table-of-contents">
<p class="topic-title first"><a name="table-of-contents">Table of Contents</a></p>
<ul class="auto-toc simple">
<li><a class="reference" href="#synergies-with-static-assertions" id="id1" name="id1">1&nbsp;&nbsp;&nbsp;Synergies with Static Assertions</a><ul class="auto-toc">
<li><a class="reference" href="#alternatives" id="id2" name="id2">1.1&nbsp;&nbsp;&nbsp;Alternatives</a></li>
</ul>
</li>
<li><a class="reference" href="#synergies-with-concepts" id="id3" name="id3">2&nbsp;&nbsp;&nbsp;Synergies with Concepts</a><ul class="auto-toc">
<li><a class="reference" href="#concept-notation" id="id4" name="id4">2.1&nbsp;&nbsp;&nbsp;Concept notation</a></li>
<li><a class="reference" href="#concept-assertions" id="id5" name="id5">2.2&nbsp;&nbsp;&nbsp;Concept assertions</a></li>
</ul>
</li>
<li><a class="reference" href="#synergies-with-concepts-and-static-assertions" id="id6" name="id6">3&nbsp;&nbsp;&nbsp;Synergies with Concepts and Static Assertions</a></li>
<li><a class="reference" href="#conclusion" id="id7" name="id7">4&nbsp;&nbsp;&nbsp;Conclusion</a></li>
<li><a class="reference" href="#acknowledgements" id="id8" name="id8">5&nbsp;&nbsp;&nbsp;Acknowledgements</a></li>
</ul>
</div>
<div class="section" id="synergies-with-static-assertions">
<h1><a class="toc-backref" href="#id1" name="synergies-with-static-assertions">1&nbsp;&nbsp;&nbsp;Synergies with Static Assertions</a></h1>
<p>To compare the details of the two proposals, we refer to
the individual papers:</p>
<ul class="simple">
<li><a class="reference" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1720.html">Proposal to Add Static Assertions to the Core Language (Revision 3)</a></li>
<li><a class="reference" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1773.html">Proposal to add Contract Programming to C++ (revision 2)</a></li>
</ul>
<p>The first proposal suggests the addition of a new keyword <tt class="docutils literal"><span class="pre">static_assert</span></tt>
which may be used as in</p>
<pre class="literal-block">
template &lt;ValueType charT, class traits&gt;
class basic_string 
{
    static_assert( tr1::is_pod&lt;charT&gt;::value,
                   &quot;Template argument charT must be a POD type in class template basic_string&quot; );
            // ...
};
</pre>
<p>Such a statement may appear in</p>
<ul class="simple">
<li>namespace scope</li>
<li>class scope</li>
<li>block scope</li>
</ul>
<p>In the Contract Programming proposal, there are currently two
mechanisms for static assertions:</p>
<ol class="arabic simple">
<li><tt class="docutils literal"><span class="pre">static</span> <span class="pre">invariant</span> <span class="pre">{</span></tt>  <em>constant-expression</em> <tt class="docutils literal"><span class="pre">;</span> <span class="pre">}</span></tt></li>
<li><tt class="docutils literal"><span class="pre">precondition</span> <span class="pre">{</span> <span class="pre">static</span></tt>  <em>constant-expression</em> <tt class="docutils literal"><span class="pre">;</span> <span class="pre">}</span></tt></li>
</ol>
<p>The <tt class="docutils literal"><span class="pre">static</span> <span class="pre">invariant</span></tt> is allowed to appear at</p>
<ul class="simple">
<li>namespace scope</li>
<li>class scope</li>
</ul>
<p>The second mechanism is only valid within pre- and post-conditions.
So the current Contract Programming proposal would not allow 
static assertions at namespace scope.
(Remark: the reader might want to consider the new syntax in the
latest revision of the Contract Programming paper, <a class="reference" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1866.html">n1866</a>.)</p>
<div class="section" id="alternatives">
<h2><a class="toc-backref" href="#id2" name="alternatives">1.1&nbsp;&nbsp;&nbsp;Alternatives</a></h2>
<p>Imagine for a moment that <tt class="docutils literal"><span class="pre">static</span> <span class="pre">invariant</span></tt> was allowed to
appear in</p>
<ul class="simple">
<li>namespace scope</li>
<li>class scope</li>
<li>block scope</li>
</ul>
<p>Then the two proposals would be completely overlapping.</p>
<p>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:</p>
<ul class="simple">
<li><a class="reference" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1521.pdf">Generalized Constant Expressions</a></li>
</ul>
<p>The above paper introduces the highly desirable notion of 
<em>constant-valued</em> functions such that all inline functions  
recursively defined only in terms of constants yield a compile-time
constant.</p>
<p>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</p>
<pre class="literal-block">
template&lt; unsigned Size &gt; 
struct array
{
    template&lt; unsigned N &gt;
    T&amp; at()
    precondition
    {
        static N &lt; Size;
    }
</pre>
<p>which now is</p>
<pre class="literal-block">
template&lt; unsigned N &gt;
T&amp; at()
precondition
{
    N &lt; Size;
}
</pre>
<p>The good consequence is of course that a user cannot forget to put the <tt class="docutils literal"><span class="pre">static</span></tt>
keyword there---it just works as we would like it to.
(Remark: this is exactly what we have done in <a class="reference" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1866.html">n1866</a>.)</p>
</div>
</div>
<div class="section" id="synergies-with-concepts">
<h1><a class="toc-backref" href="#id3" name="synergies-with-concepts">2&nbsp;&nbsp;&nbsp;Synergies with Concepts</a></h1>
<p>Concepts are proposed in two different papers:</p>
<ul class="simple">
<li><a class="reference" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1758.pdf">Concepts for C++0x</a> (Indiana proposal)</li>
<li><a class="reference" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1782.pdf">A concept design</a> (Texas proposal)</li>
</ul>
<p>Both proposals define concepts completely in terms of syntactical 
requirements.</p>
<p>A concept requirement as specified in the standard includes both syntactic 
requirements and (operational) semantic requirements. The latter cannot be 
specified with concepts, but can to a large extend to specified with 
Contract Programming.</p>
<p>In would be fair to say that Concepts and Contract Programming are
largely orthogonal proposals that can be put in the language independently
of each other. However, there are major benefits of having both:</p>
<ol class="arabic simple">
<li>We can specify both syntactic and semantic requirements</li>
<li>We can put the contract on the concept and hence avoid to repeat it
on each implementation of a concept.</li>
</ol>
<div class="section" id="concept-notation">
<h2><a class="toc-backref" href="#id4" name="concept-notation">2.1&nbsp;&nbsp;&nbsp;Concept notation</a></h2>
<p>The particular notation used to define a concept greatly
affects the aesthetics and/or possibility of specifying 
contracts on Concepts.</p>
<p>Basically two ways of defining concepts are being 
proposed:</p>
<ul class="simple">
<li>pseudo-signatures, and</li>
<li>usage patterns.</li>
</ul>
<p>In the former syntax, we could define a concept as follows:</p>
<pre class="literal-block">
template&lt;typeid T&gt;
concept EqualityComparable 
{
    bool operator==(T a, T b);
    bool operator!=(T a, T b);
};  
</pre>
<p>It is quite easy and natural to add contracts to this definition:</p>
<pre class="literal-block">
template&lt;typeid T&gt;
concept EqualityComparable 
{
    bool operator==(T a, T b)
        postcondition( result ) { result == !( a != b ); }

    bool operator!=(T a, T b)
        postcondition( result ) { result == !( a == b ); }
};  
</pre>
<p>Remark: there is no infinite recursion problems here since postconditions
do not check contracts.</p>
<p>In the spirit of usage patterns, we would write the concept
as:</p>
<pre class="literal-block">
concept EqualityComparable&lt; class T &gt; 
{
    T a;
    T b;
    bool( a == b );
    bool( a == b );
};  
</pre>
<p>When we try to put contracts into this definition, it looks somewhat
different:</p>
<pre class="literal-block">
concept EqualityComparable&lt; class T &gt; 
{
    T a;
    T b;
    bool( a == b )
        postcondition( result ) { result == !( a != b ); }
        
    bool( a == b )
        postcondition( result ) { result == !( a == b ); }
};  
</pre>
<p>This might not look too bad, but now consider</p>
<pre class="literal-block">
concept RandomAccessContainer&lt; class T &gt;
{
    T t;
    const T u;

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

    T::value_type&amp; v = t[5]
        precondition { /* how do we refer to the argument here??? */ }              
};
</pre>
<p>Thus the usage pattern approach does not mix well with contract programming.</p>
</div>
<div class="section" id="concept-assertions">
<h2><a class="toc-backref" href="#id5" name="concept-assertions">2.2&nbsp;&nbsp;&nbsp;Concept assertions</a></h2>
<p>This section discusses potential reuse of keywords.</p>
<p>In the Indiana proposal, the keyword <tt class="docutils literal"><span class="pre">require</span></tt> is used to
make an assertion about nested types:</p>
<pre class="literal-block">
template&lt; typeid X &gt;
concept Container 
{
    ...
    require typename X::iterator;
    require InputIterator&lt;X::iterator&gt;;
    ...
};
</pre>
<p>It might be ok to reuse <tt class="docutils literal"><span class="pre">static</span> <span class="pre">invariant</span></tt> (or simply <tt class="docutils literal"><span class="pre">invariant</span></tt>) here:</p>
<pre class="literal-block">
template&lt; typeid X &gt;
concept Container 
{
    ...
    static invariant
    {
        typename X::iterator;
        InputIterator&lt;X::iterator&gt;;
    }    
    ...
};
</pre>
<p>Both proposals define ways to explicitly state that
a UDT adheres to a particular concept. In the
Texas proposal the keyword <tt class="docutils literal"><span class="pre">static_assert</span></tt> is used as
follows:</p>
<pre class="literal-block">
static_assert Forward_iterator&lt;Ptr_to_int&gt;;
</pre>
<p>where <tt class="docutils literal"><span class="pre">Forward_iterator&lt;Ptr_to_int&gt;</span></tt> can simply be
thought of a predicate. It might not be too bad to say</p>
<pre class="literal-block">
static invariant
{
    Forward_iterator&lt;Ptr_to_int&gt;;
}
</pre>
<p>instead. <tt class="docutils literal"><span class="pre">static</span> <span class="pre">invariant</span></tt> has a natural 
block structure that will make it easier to specify
several predicates.</p>
</div>
</div>
<div class="section" id="synergies-with-concepts-and-static-assertions">
<h1><a class="toc-backref" href="#id6" name="synergies-with-concepts-and-static-assertions">3&nbsp;&nbsp;&nbsp;Synergies with Concepts and Static Assertions</a></h1>
<p>Consider again the fixed-size array class:</p>
<pre class="literal-block">
template&lt; class T, unsigned Size &gt;
struct array
{
    ...
</pre>
<p>and let us define a function template <tt class="docutils literal"><span class="pre">min_value()</span></tt>
which does not work when <tt class="docutils literal"><span class="pre">Size</span> <span class="pre">==</span> <span class="pre">0</span></tt>.</p>
<p>With <tt class="docutils literal"><span class="pre">static_assert</span></tt> we might say</p>
<pre class="literal-block">
template&lt; class T, std::size_t N &gt; 
const T&amp; min_value( const std::array&lt;T, N&gt;&amp; x )
{ 
    static_assert( N &gt; 0, &quot;...&quot; ); 
    ... 
}
</pre>
<p>With Contract Programing we might say</p>
<pre class="literal-block">
template&lt; class T, std::size_t N &gt; 
const T&amp; min_value(const std::array&lt;T, N&gt;&amp; x)
    precondition { N &gt; 0; }
</pre>
<p>The advantage is here that the error will point to the declaration
of the function and not the implementation.</p>
<p>With Concepts we might say</p>
<pre class="literal-block">
template&lt; class T, std::size_t N &gt; 
    where { N &gt; 0 }
const T&amp; min_value(const std::array&lt;T, N&gt;&amp; x);
</pre>
<p>So there is considerable overlap in this example.</p>
</div>
<div class="section" id="conclusion">
<h1><a class="toc-backref" href="#id7" name="conclusion">4&nbsp;&nbsp;&nbsp;Conclusion</a></h1>
<p>The functionality provided by 
Contract Programming and <tt class="docutils literal"><span class="pre">static_assert</span></tt> completely overlap. 
The main difference will be that in Contract Programming
the compound keyword <tt class="docutils literal"><span class="pre">static</span> <span class="pre">invariant</span></tt> (or simply <tt class="docutils literal"><span class="pre">invariant</span></tt>)
will be used instead.
It is thus possible to save a keyword.</p>
<p>The functionality provided by Concepts and Contract Programming
are orthogonal. The two mechanisms complement each other well
and if contracts are specified in concepts, the UDT automatically
reuses the contracts from the concept.</p>
<p>If concepts are specified with usage patterns, it becomes difficult
to attach contracts to them because there is no
way to refer to the arguments of function; pseudo-signatures do not
have this problem.</p>
<p>In both concept proposals, <tt class="docutils literal"><span class="pre">static</span> <span class="pre">invariant</span></tt> (or simply <tt class="docutils literal"><span class="pre">invariant</span></tt>) might be
reused to specify compile-time assertions in various contexts.</p>
</div>
<div class="section" id="acknowledgements">
<h1><a class="toc-backref" href="#id8" name="acknowledgements">5&nbsp;&nbsp;&nbsp;Acknowledgements</a></h1>
<p>The authors would like to thank James Widman for
his feedback.</p>
</div>
</div>
</body>
</html>
