On 14.05.2017 00:07, Petar Kirov [ZombineDev] wrote:
>>
>> How would you feel about:
>>
>> if(condition){ then(); }
>> { otherwise(); }
>
> I don't see any problem, ...

The intention is that in this _hypothetical_ (hence "would") grammar (which is somewhat analogous to what is proposed in 3), the second block would bind to the if-statement as the 'else' case, but I see how that is confusing.

> And my case still stands - if you were to format the code like this:

Again, this is not about formatting. Reformat the code as you wish. With your reformatting, it would actually be even less obvious.

On Saturday, 13 May 2017 at 10:46:51 UTC, Jonathan M Davis wrote:
> be DOA. And not having them definitely simplifies lexing and parsing D code, so it's quite understandable that Walter is against them.

I don't see how it complicates the lexer? "body" would be a valid identifier, so it would be lexed as such. All the parser has to do is to check the content of the identifer-token.

On 5/13/17 6:07 PM, Petar Kirov [ZombineDev] wrote:
> 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(); }
>
> I don't see any problem, in fact this is valid code even today - both in
> C++ and D.
> And my case still stands - if you were to format the code like this:
>
> if (condition)
> {
>     then();
> }
>
> {
>     otherwise();
> }
>
> then the intent would be more obvious. At least in C++ using a plain
> scope { }
> is common idiom used to explicitly limit the lifetime of RAII objects
> declared
> within it.

There is a huge difference. if() {} else {} is semantically completely different than if() {} {}

Currently, we already allow omitting body when in/out aren't present:

void foo()
{
}

is equivalent to

void foo()
body
{
}

I think really, option 1 is both the easiest and least disruptive. I'm OK with option 3, but it sure seems like an unnecessary breakage.

-Steve

On Sunday, 14 May 2017 at 13:04:12 UTC, Steven Schveighoffer wrote:
> On 5/13/17 6:07 PM, Petar Kirov [ZombineDev] wrote:
>> 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:
>>>>> [...]
>>>>
>>>> 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(); }
>>
>> I don't see any problem, in fact this is valid code even today - both in
>> C++ and D.
>> And my case still stands - if you were to format the code like this:
>>
>> if (condition)
>> {
>>     then();
>> }
>>
>> {
>>     otherwise();
>> }
>>
>> then the intent would be more obvious. At least in C++ using a plain
>> scope { }
>> is common idiom used to explicitly limit the lifetime of RAII objects
>> declared
>> within it.
>
> There is a huge difference. if() {} else {} is semantically completely different than if() {} {}

Obviously. I was just referring to the fact 'if (expr) {} {}' is already valid today and I don't think it confuses anyone with 'if (expr) {} else {}', *if code is formatted and/or commented properly*.

> Currently, we already allow omitting body when in/out aren't present:
>
> void foo()
> {
> }
>
> is equivalent to
>
> void foo()
> body
> {
> }
>
> I think really, option 1 is both the easiest and least disruptive. I'm OK with option 3, but it sure seems like an unnecessary breakage.
>
> -Steve

By making body optional and a contextual keyword there should be no breaking changes (except for obscure code like `static assert (!__traits(compiles, { mixin ("int body;"); }))` :D).

On Sunday, 14 May 2017 at 01:30:19 UTC, Timon Gehr wrote:
> On 14.05.2017 00:07, Petar Kirov [ZombineDev] wrote:
>>>
>>> How would you feel about:
>>>
>>> if(condition){ then(); }
>>> { otherwise(); }
>>
>> I don't see any problem, ...
>
> The intention is that in this _hypothetical_ (hence "would") grammar (which is somewhat analogous to what is proposed in 3), the second block would bind to the if-statement as the 'else' case, but I see how that is confusing.
>
>> And my case still stands - if you were to format the code like this:
>
> Again, this is not about formatting. Reformat the code as you wish. With your reformatting, it would actually be even less obvious.

I now see what you meant, but the two ideas are not equivalent.
Making 'else' optional is not possible, because it can change
the meaning of existing code, while making 'body' optional would not.

Edit: I may be wrong. Here's a case that's on the edge of ambiguity:

void main()
{
    void inner(int x)
    in { }
    {
        writeln("WAT");
    }
}

If 'body' was optional, what would be the output of the program? It turns out
that the output would be empty, because function bodies are required for functions
with 'in' or 'out' contracts, making the block bind to the 'inner' function,
instead of 'main'.

On 5/14/17 9:24 AM, Petar Kirov [ZombineDev] wrote:
>
> By making body optional and a contextual keyword there should be no
> breaking changes (except for obscure code like `static assert
> (!__traits(compiles, { mixin ("int body;"); }))` :D).

It doesn't even need to be optional. It can be required as it is now (when in/out are specified), just not a keyword. I believe that this is what is specified in Option 1 of the DIP.

-Steve

On Sunday, 14 May 2017 at 13:55:44 UTC, Steven Schveighoffer wrote:
> On 5/14/17 9:24 AM, Petar Kirov [ZombineDev] wrote:
>>
>> By making body optional and a contextual keyword there should be no
>> breaking changes (except for obscure code like `static assert
>> (!__traits(compiles, { mixin ("int body;"); }))` :D).
>
> It doesn't even need to be optional. It can be required as it is now (when in/out are specified), just not a keyword. I believe that this is what is specified in Option 1 of the DIP.
>
> -Steve

Yeah, I'm OK with Option 1. I would just prefer not typing 'body' when writing functions with contracts.

On 5/14/17 9:53 AM, Petar Kirov [ZombineDev] wrote:

> Edit: I may be wrong. Here's a case that's on the edge of ambiguity:
>
> void main()
> {
>     void inner(int x)
>     in { }
>     {
>         writeln("WAT");
>     }
> }
>
> If 'body' was optional, what would be the output of the program? It
> turns out
> that the output would be empty, because function bodies are required for
> functions
> with 'in' or 'out' contracts, making the block bind to the 'inner'
> function,
> instead of 'main'.
>

I don't think this is ambiguous or controversial. We are used to a block that follows a function declaration being that function's body without a special keyword.

Look at it this way:

void inner(int x) // in {}
{
   writeln("Yeah, this is normal");
}

If you uncomment the in clause, it's still pretty normal looking.

Not that I'm particularly arguing for making body always optional, I'm fine with continuing to require it. But it's also fine to make it optional IMO.

-Steve

On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
> [1] Also, here is a list of existing contextual keywords:
>
> exit
> success
> failure
> C
> C++
> D
> Windows
> Pascal
> System
> Objective-C

They are not used alone. They are used in a **statement** and surrounded by parens.
It's important because statements start with keywords, which, in a way, makes the contextual keyword less important.

"body" as contextual keyword would be only comparable if
1/ "in" and "out" would also be contextual keywords. For example "exit", "success" and "failure" are **all** contextual keywords.
2/ used in a statement, for example "contract": void foo() contract(in){}contract(out){} contract(body){} (i don't say that this is the way to follow, it's more theoretical)

On 5/12/2017 9:17 AM, Mike Parker wrote:
> The first stage of the formal review for DIP 1003 [1], "Remove body as a
> Keyword", is now underway.

A combination of Options 1 and 2:

1. Introduce 'function' as an alternative to 'body'.
2. Turn 'body' into a contextual keyword.
3. Deprecate 'body' as a contextual keyword.
4. Eventually remove 'body' as a contextual keyword.

The advantages of this are:

1. 'body' can immediately be used as a regular identifier.
2. Existing code is not immediately broken.
3. Can have a decent deprecation period for users using 'body'.
4. No long term problems with contextual keywords.