DIP 1003: remove `body` as a keyword

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.11.2016 um 23:37 schrieb Timon Gehr:
> On 22.11.2016 20:05, Meta wrote:
>> On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:
>>> Am 21.11.2016 um 22:19 schrieb Timon Gehr:
>>>> 3 is ambiguous.
>>>
>>> Can you give an example?
>>
>> I'm curious as well. I considered that option 3 might be ambiguous but I
>> managed to convince myself that it wouldn't be. I'm guessing you're
>> referring to the fact that:
>>
>> {
>>     //function body
>> }
>>
>> Is a delegate literal, which could conceivably conflict with Option 3's
>> syntax?
>>
>> void fun(ref int n)
>> in { assert(n > 0); }
>> out { assert(n > 0); }
>> { //Is this a syntax error or an immediately executed delegate literal?
>>     n += 1;
>> }()
>
>
> Function declarations don't necessarily have a body, but they might have
> contracts. (This is currently not allowed for technical reasons, but it
> should/will be.) But this is a rather minor point (usually you don't
> want to have contracts without implementation in a context where
> something starting with '{' is allowed).

Okay, but that doesn't sound like there is a technical ambiguity here, 
then? Since there must be a full (block) statement after the in/out, it 
should always resolve naturally.

>
> The more important point is that there is no precedent where {...}{...}
> are two components of the same entity, it looks ugly even with the
> space-wasting convention where '{' is put on its own line. Not all
> contracts are one-liners like in your example above (which looks almost
> tolerable).

It can happen all the time with normal block statements. Especially 
something like 'scope' that works outside of the normal program flow has 
a certain similarity:

     scope (exit) { assert(n > 0); }
     {
         n += 1;
     }

What I personally dislike more is that adding something that should be 
an independent component of the function signature (e.g. an "int" 
contract) changes the syntax of the body definition. That always strikes 
me as an odd non-orthogonal part of the syntax.