"body" keyword is unnecessary

Steven Schveighoffer schveiguy at yahoo.com
Thu Mar 24 12:55:50 PDT 2011


On Wed, 23 Mar 2011 18:17:32 -0400, Alvaro <alvaroDotSegura at gmail.com>  
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


More information about the Digitalmars-d mailing list