"body" keyword is unnecessary

[Jonathan M Davis]

> I definitely had "in" as a problem. Its because some people like to
> use that in C code. (Qt being the most recent example).
> 
> I've also had issues with "string". That one can be common in C code.
> Its a pretty bad habit of naming your variables for what type they are
> instead of their purpose. I guess it fits into that whole "I'll hack
> it just for now, and fix it never" mentality.

_Any_ keyword can conflict with a variable name. Some - like const - aren't 
terribly likely to be names that a programmer will want to use for a variable, 
but most of them are. Well-selected keywords do a good job of describing what 
they're for - just like well-selected variable names. So, there's going to be 
some overlap between good keywords and good variable names. Such is life with  
pretty much any programming language. And taking code in one programming 
language with a certain set of keywords and porting it to another with a 
different set of keywords is bound to run into trouble from time to time.

Now, string is pretty bad on the whole, but then again, there are plenty of 
cases where you just don't care about what a string is for and str or string 
makes perfect sense (a prime example would be functions which operate on 
general strings - such as std.string). IIRC, there are parameters in std.array 
called array, simply because you don't care what the array is for. The fact 
that it's an array is all that matters.

Regardless, no matter what keywords a language picks, they'll conflict with 
variable names that programmers want to use unless they're complete gibberish 
such as aesnth or rcoevw, and such keywords would be _horrible_.

- Jonathan M Davis