On Wed, 23 Mar 2011 18:17:32 -0400, Alvaro <[email protected]>
wrote:
D already has a long list of keywords, reserved words can't be used as
identifiers, which can be annoying. "body" in particular is a common
noun that programmers would gladly use as a variable name in physics
simulation, astronomy, mechanics, games, health, etc. I think "body" can
be removed from D with no harm, and with the benefit of allowing the
name as identifier.
Rationale: Functions in C and derived languages have always had a body
and they never needed a keyword. In D, "body" is used to mark the actual
body of a function after the optional "in" and/or "out" contract blocks.
What is different in the body itself of a function with and without
contracts to make one body{...} and the other {...}?
Example:
int myfunc(int x)
in{
...contract preconditions...
}
out (result){
...contract postconditions...
}
body{
...code...
}
But we don't write:
int myfunc(int x)
body{
...code...
}
The body keyword can be omitted and still interpret the code correctly
given this rule: "An unnamed {...} block right after an in{} or out{}
block when defining a function, MUST be the function's body". Thus, the
above code would become:
int myfunc(int x)
in{
...contract preconditions...
}
out (result){
...contract postconditions...
}
{
...code...
}
and be perfectly understandable, with the benefit of one less keyword.
The compiler, upon reading the opening "{" after the out block, would
know it is the beginning of the function body.
Or I am missing something that would overcomplicate parsing, etc?
Most likely it's not necessary.
But I don't know that it's so terrible to have it as a keyword. Clearly
there was a "free keyword love" period in D's past, but I think it takes a
lot more than just "we could technically do this without a keyword" to
remove it from the language. For one, it would break tons of existing
code.
I wouldn't mind it becoming a contextual keyword (like C#'s get and set
inside properties).
One thing it does help with is it provides a visual (and searchable)
anchor for a person reading a function. For example if preconditions and
postconditions come before the body and are quite long, being able to do
/body in vi is nice. It also would seem like something was missing if it
was just blank (of course, only when the in/out contracts are there).
-Steve
