DIP 1003: remove `body` as a keyword

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, November 19, 2016 21:16:15 Dicebot via Digitalmars-d-announce 
wrote:
> DIP 1003 is merged to the queue and open for public informal
> feedback.
>
> PR: https://github.com/dlang/DIPs/pull/48
> Initial merged document:
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
>
> If you want the change to be approved and have ideas how to
> improve it to better match on
> https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and
> existing published reviews - please submit new PR with editorial
> and ping original author.

Personally, I don't care much about having body as a usable symbol. It
occasionally would be useful, but I can live without it. However, I _do_
find it very annoying that it's required for the function body when you have
contracts. After all, it's not required when you write the function
normally. Why should it be required when you have contracts on the function?
The braces after the contracts are clearly for the function body. They
couldn't be for anything else. The compiler always requires that the body be
last after the in and out contracts, making the body keyword totally
redundant. So, I've never understood why the body keyword was required. As
far as I can tell, it fixes no ambiguity. It's just extra typing, and it
makes contracts that much more verbose, which makes me that much more
inclined to just not bother with them and put the assertions in the function
body - particularly when I'm already of the opinion that they add no value
outside of inheritance, because assertions at the beginning of the function
take care of in contracts, and unit tests are really what covers the out
contract case anyway (particularly since it's very rare that you can have a
general test for the out contract rather than testing that specific input
results in specific output).

That being said, I don't care about option 1. Adding a contextual keyword
just to get the body keyword is not worth the tradeoff as far as I'm
concerned.

Option 2 is also pointless IMHO, because you _still_ have a pointless
keyword sitting on the function body. All it's doing is trying to get the
body keyword back for general use, which might be nice, but it seems to me
that the important thing here is to get rid of the pointless and annoying
keyword on the function body, and swapping one keyword for another, longer
keyword is most definitely not an improvement in that regard.

IMHO, option 3 is what we should have done ages ago. Even if the keyword had
been something like xyzzy rather than something that a number of folks want
to use for a symbol name, it still shouldn't have been there, because it
adds no value and helps to make contracts even more verbose.

- Jonathan M Davis