If so, I think I found another bug.
DLI gives the error "{ } statement expected after invariant" on the
following code:

class Foo
{
  invariant()
  {
    assert(true);
  }
}

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3D91C09D.A84CE13E@deming-os.org:

> If so, I think I found another bug.
> DLI gives the error "{ } statement expected after invariant" on the
> following code:
> 
> class Foo
> {
>   invariant()
>   {
>     assert(true);
>   }
> }

Take the () off the end of invariant

Patrick Down wrote:
> Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3D91C09D.A84CE13E@deming-os.org:
> 
> 
>>If so, I think I found another bug.
>>DLI gives the error "{ } statement expected after invariant" on the
>>following code:
>>
>>class Foo
>>{
>>  invariant()
>>  {
>>    assert(true);
>>  }
>>}
> 
> 
> Take the () off the end of invariant

Thanks, that fixed it.

The spec shows parentheses, though.

"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D91D764.7060104@deming-os.org...
> > Take the () off the end of invariant
>
> Thanks, that fixed it.
> The spec shows parentheses, though.

Oops!

Russ Lewis wrote:
> If so, I think I found another bug.
> DLI gives the error "{ } statement expected after invariant" on the
> following code:
> 
> class Foo
> {
>   invariant()
>   {
>     assert(true);
>   }
> }

DLI does not generate code for class invariants or in/out contracts yet.  The only contracts supported are unittests.  It's on my TODO; there's nothing really holding it back (the machine just needs a place to hook in out blocks for return statements, and these don't affect exceptions) but for time.