DIP 1003 Formal Review

[Eugene Wissner via Digitalmars-d]

On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
> On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
>> On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
>>> On 12.05.2017 18:17, Mike Parker wrote:
>>>> The first stage of the formal review for DIP 1003 [1], 
>>>> "Remove body as a
>>>> Keyword", is now underway. From now until 11:59 PM ET on May 
>>>> 26 (3:59 AM
>>>> GMT on May 27), the community has the opportunity to provide 
>>>> last-minute
>>>> feedback. If you missed the preliminary review [2], this is 
>>>> your chance
>>>> to provide input.
>>>>
>>>> At the end of the feedback period, I will submit the DIP to 
>>>> Walter and
>>>> Andrei for their final decision. Thanks in advance to those 
>>>> of you who
>>>> participate.
>>>>
>>>> [1]
>>>> https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>>>>
>>>>
>>>>
>>>> [2] 
>>>> http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>>>
>>> Option 1 is good: There is nothing wrong with the current 
>>> syntax. [1]
>>>
>>> Option 2 is bad: It's the function body, not the function.
>>>
>>> Option 3 is ugly: There is no precedent for '...{}{}' 
>>> belonging to the
>>> same declaration or statement.
>>
>> Hmm, I guess it depends on how you format your code.
>
> No, it does not. This was a point about the grammar.
>
> How would you feel about:
>
> if(condition){ then(); }
> { otherwise(); }

It isn't the same.

1) It is ambiguous: { otherwise(); } can be a statement in a 
block or an else condition. But it wasn't the real point.
2) Nested ifs are used much more often than nested functions, and 
the code with a lot of nested ifs would look unreadable without 
else. It isn't the case for the functions. I suppose that 
contracts a mostly used on outer functions and it would look 
pretty clear.