contract programming without a function

[Jan Hanselaer]

"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? But the intention is to extend the possibilities? 
If not, I'd still like to see al little example.