contract programming without a function

[Derek Parnell]

On Sun, 20 May 2007 12:10:33 +0200, Jan Hanselaer wrote:

> "Jari-Matti Mäkelä" <jmjmak at utu.fi.invalid> schreef in bericht 
> news:f2p10j$fkf$1 at digitalmars.com...
>> Jan Hanselaer wrote:
>>
>>>
>>> "Tyler Knott" <tywebmail at mailcity.com> schreef in bericht
>>> news:f2ogbj$2kp6$1 at digitalmars.com...
>>>> You just got the syntax of the contracts slightly wrong.  This is the
>>>> correct version:
>>>>
>>>> bool fooFunc(Foo* f)
>>>>     in
>>>>     {
>>>>         assert(f !is null);
>>>>     }
>>>>     out (result)
>>>>     {
>>>>         assert(f.fooWasDone());
>>>>         assert(result == true);
>>>>     }
>>>>     body
>>>>     {
>>>>         bool fooVal;
>>>>         fooVal = f.doFoo();
>>>>         return fooVal;
>>>>     }
>>>>
>>>> Note that the in, out, and body are not wrapped in curly braces and that
>>>> the in and out contracts can't access variables from the body contract
>>>> (because they are in different scopes), though the in and out contracts
>>>> can access the arguments and the out contract can also access the return
>>>> value (as an optional parameter passed to it).  Finally, keep in mind
>>>> that the in and out contracts (like asserts) aren't included when the
>>>> compiler is set to release mode so don't put critical error checking in
>>>> them (they're intended to be used to help verify program correctness
>>>> while you're developing the program).
>>>
>>> Actually I know all this, and I've been using it this way. Maybe the
>>> example I gave was a bit misleading but what I actualy want to know is if
>>> it's possible to use these pre- and postconditions somewhere else then
>>> with a function body. Because in the manual they state that with a 
>>> funtion
>>> is "the most typical use", so I'm asking myself what the other uses could
>>> be.
>>
>> Of course there could be other places too. One particularly interesting 
>> and
>> useful feature would be support for contracts in interfaces. From the
>> language user's point of view contracts aren't very polished or consistent
>> at the moment. Hopefully they will be one of the important features on
>> Walter's todo list right after the constness and ast macro stuff.
>>
>>>
>>> Jan
>>
> 
> Do I understand correct that for the moment contract programming is only 
> possible with functions? 

Contract Programming is more than just the 'in', 'out' and 'body'
constructs. Those ones are specifically designed for functions though. 

The other constructs that go to implementing CP are the 'invariant' and
'assert'. Invariant is specifically designed to work with classes. Assert
is designed to work with statements.

In summary ...

'in' is executed before its function is entered.
'out' is executed after its function returns.
'invariant' is executed after /any/ class member function returns.
'assert' is executed whenever statement control flow gets to it.

It sounds like the assert construct is all you need to exercise CP inside a
function.


When the documenation say "the most typical use" i think it is referring to
why one would be using these constructs not where one would be using them.

> But the intention is to extend the possibilities? 
> If not, I'd still like to see al little example.

void main()
{
   bool assign = false;
   int x;
   assert(assign);
   {x = 1;}
}


I don't believe that 'in' and 'out' can yet be used for nested functions or
anonymous functions.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell