Davidson Corry <[email protected]> wrote:
> On 10/27/2011 2:12 PM, Timon Gehr wrote:
>> Yes, this design has indeed a keyword-issue that your proposal has not.
>> I am all for not making it a keyword. The 'body' keyword imho should be
>> removed too, there is only one place in the grammar where it is ever
>> needed (and there it is completely redundant), therefore it could just
>> be lexed as an identifier. That would not break any code.
>
> Agreed. In fact, it occurred to me the other day that we could write
> contracts as
>
> void foo(T t)
> {
> scope(in) {
> // pre-condition contracts
> }
> scope(out) {
> // post-condition contracts
> }
> // ...body of function...
> }
>
> and eliminate the 'in', 'out' and 'body' keywords/constructs entirely.
>
> Similarly, an invariant could appear in the default constructor of a class as
>
> this()
> {
> scope(invariant) {
> // invariant guarantees...
> }
> // ...body of constructor...
> }
>
> Or *any* constructor, really, although you would probably want the
> compiler to enforce that no more than one constructor defined a
> scope(invariant) block. This notation also suggests (correctly) that the
> invariant doesn't take effect until you have entered the constructor.
> (Exited it, really, but...)
>
> -- Davidson
The contracts are parts of the function's interface, not implementation. If
you put the scope(in/out) inside the '{ ... }' how would a .di file handle
it?
And class invariant is also checked outside the constructor. Your syntax
makes it look like it will run only when the constructor is called.
