www.digitalmars.com         C & C++   DMDScript  

D - contract thoughts

reply "chris jones" <flak clara.co.uk> writes:
It seems to me the syntax is inconsistent with the rest of the language. The
contracts belong to the function but are not enclosed in a block as all
other code is. I think the function brakets should enclose the contracts
somthing like this....

long square_root(long x)
{
in
  {
  assert(x >= 0);
  }
out (result)
  {
  assert((result * result) == x);
  }
return math.sqrt(x);
}

Its one less keyword to worry about :) Or mabey like this...
long square_root(long x)
{in
  {
  assert(x >= 0);
  }
out (result)
  {
  assert((result * result) == x);
  }
body  {  return math.sqrt(x);  }
}
easier to read but more typing.chris
Oct 13 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
chris jones wrote:

 It seems to me the syntax is inconsistent with the rest of the language. The
 contracts belong to the function but are not enclosed in a block as all
 other code is. I think the function brakets should enclose the contracts
 somthing like this....
I hear you, but in my view, Walter's syntax is better. I see a function as two things: 1) A declaration that determines its interface with the other parts of the program 2) An internal implementation IMHO, the contracts are parts of the interface, just like the function argument types and return type are. Hopefully, we will eventually have compilers that will be able to check these contracts pretty thoroughly at runtime. Compilers already tell us that a certain set of arguments isn't valid; I want compiler to also tell us, at compile time, that the arguments we pass to a function are invalid. Likewise, I want the compiler to tell us that a certain function is obviously in error because it cannot fulfill its out conditions, just like current compilers tell you "function must return a value" and such. -- 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))) ]
Oct 13 2002
parent Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Russ Lewis wrote:
 chris jones wrote:
 
 
It seems to me the syntax is inconsistent with the rest of the language. The
contracts belong to the function but are not enclosed in a block as all
other code is. I think the function brakets should enclose the contracts
somthing like this....
I hear you, but in my view, Walter's syntax is better. I see a function as two things: 1) A declaration that determines its interface with the other parts of the program 2) An internal implementation IMHO, the contracts are parts of the interface, just like the function argument types and return type are. Hopefully, we will eventually have compilers that will be able to check these contracts pretty thoroughly at runtime. Compilers already tell us that a certain set of arguments isn't valid; I want compiler to also tell us, at compile time, that the arguments we pass to a function are invalid. Likewise, I want the compiler to tell us that a certain function is obviously in error because it cannot fulfill its out conditions, just like current compilers tell you "function must return a value" and such.
I suppose that it would be most logical to make them look like this: in { ...tests... } uint myfunc(..args..) { ...code... } out (result) { ...more tests... } since it doesn't ugly up the function body, and gives you a real idea of that's going to happen about the order in which these tests are executed. Whether or not you like it, it would be cool if it were an option syntactically. Evan
Oct 14 2002