On Sun, 28 Aug 2016 08:35:06 +0000, ketmar wrote:
> i have a perfect solution to this: don't write such code!

It would reflect poorly on the compiler if it failed to compile something simply because you added a few comments. Especially since each C-style comment is likely its own token. A not-absurd usecase is a person condensing several functions into one, which might involve separately commenting out several function bodies.

On Sunday, 28 August 2016 at 13:26:26 UTC, Chris Wright wrote:
> On Sun, 28 Aug 2016 08:35:06 +0000, ketmar wrote:
>> i have a perfect solution to this: don't write such code!
>
> It would reflect poorly on the compiler if it failed to compile something simply because you added a few comments. Especially since each C-style comment is likely its own token. A not-absurd usecase is a person condensing several functions into one, which might involve separately commenting out several function bodies.

it has nothing to do with compiler: parser skips comments when peeking tokens. the only thing affected is simplistic syntax highlighter that can't do proper lookup.

On Sunday, 28 August 2016 at 13:35:59 UTC, ketmar wrote:
> it has nothing to do with compiler: parser skips comments when peeking tokens. the only thing affected is simplistic syntax highlighter that can't do proper lookup.

I have anyway never seen the necessity of the keyword "body" anyway. I fact, I very much dislike it. You could write a function

Fn()
in {}
out() {}
{}

or even better (or at least what I would prefer):

Fn()
{}
in {}
out() {}

The parser will always take the block without preceeding keyword as the body.
If you leave out "in" and "out", you also don't need the keyword body. As soon as you add a contract, suddenly you have to add that nasty "body". As I learned D this was confusing and I still fail to see the benefit.
If you really feel the need to make explicit where the body starts, you can add a comment:

Fn()
in
{
}
// body:
{
}
out()
{
}