On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote:
> On Friday, 12 May 2017 at 16:17:03 UTC, 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/fbb797f61ac92300eda1d63202157cd2a30ba 555/DIPs/DIP1003.md
> >
> > [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>
> I vote for option 4 - a combination of 1 and 3:
> * Make body a contextual keyword
> * Allow omitting it
> * No need for deprecation
>
> I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context:
>
> // 1:
> int C;
> C++;
>
> // 2:
> extern (C++) void foo();

Except that C++ is not a keyword anymore than linux is a keyword in

version(linux)

It's an identifier (albeit one that doesn't quite follow the normal naming scheme for identifiers). D does not have contextual keywords, and Walter is completely against adding them, so I'd expect that any proposal that required them would be DOA. And not having them definitely simplifies lexing and parsing D code, so it's quite understandable that Walter is against them.

- Jonathan M Davis

On Fri, 12 May 2017 16:17:03 +0000, 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


For option one, there would also need to be a discussion of whether to allow us to use in and out as identifiers for consistency (I used them more often than body in my pre-D programming); I would say no, but could argue either way. It's a slippery slope.


I think option three is ugly, but I could live with it. I thought ()() was ugly for templates too, but now they're just normal.

How about:

void func()
in { assert(true); }
out { assert(true); }
nowWeFinallyGetToTheFunctionBodyProvidedThereWereNoProblems {
	// I don't think we'll have to worry about name clashes...
}

On Saturday, 13 May 2017 at 10:46:51 UTC, Jonathan M Davis wrote:
> On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote:
>> On Friday, 12 May 2017 at 16:17:03 UTC, 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/fbb797f61ac92300eda1d63202157cd2a30ba 555/DIPs/DIP1003.md
>> >
>> > [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
>>
>> I vote for option 4 - a combination of 1 and 3:
>> * Make body a contextual keyword
>> * Allow omitting it
>> * No need for deprecation
>>
>> I don't buy the argument against contextual keywords. D already has them. For example 'C++' can mean two things depending on the context:
>>
>> // 1:
>> int C;
>> C++;
>>
>> // 2:
>> extern (C++) void foo();
>
> Except that C++ is not a keyword anymore than linux is a keyword in
>
> version(linux)
>
> It's an identifier (albeit one that doesn't quite follow the normal naming scheme for identifiers).

No, they're not the same. 'something' in 'version (something)' or
'debug (something)' can be either:
1) an integer
2) 'assert' or 'unittest' keyword
3) an identifier.

'debug' and 'version' identifiers live in their own namespaces which
is why they don't conflict with other identifiers in the program.
'linux' in the context of 'version (linux)' is 3) - a predefined
version identifier, and like all other identifiers it has to obey
by a certain set of rules [1]. E.g. you can't have 'version (C++-interop)'.

Contextual keywords [2] like 'C++', 'Objective-C' or 'exit' on the other hand
are not identifiers and that's why don't need to follow [1]. The fact that
the spec refuses to call them keywords [3] and they are parsed as
identifiers [4],[5] (but only the 'C' and 'Objective' parts) in dmd is
an artifact of an implementation detail. In essence, they behave exactly
as contextual keywords in C# [6].
But just for fun, let's say I play you're game. Then why not make 'body' an
identifier living in it's own namespace, just like 'failure' and 'exit'? :P

> ... and Walter is completely against adding them, so I'd expect that any proposal that required them would be DOA. And not having them definitely simplifies lexing and parsing D code, so it's quite understandable that Walter is against them.
>

You're just trying to represent Walter's opinion without adding new information.

Adding contextual keywords to a language with context free grammar won't make
the language grammar context dependent and that's why I don't buy the argument
that this would somehow complicate the process parsing D code. Yes, it may
require changes to dmd, but in general it's not a difficult problem to solve,
as other language implementation demonstrate quite well.

[0]: https://dlang.org/spec/version.html#version
[1]: https://dlang.org/spec/lex.html#Identifier
[2]: See Timon's post for a more complete list: http://forum.dlang.org/post/of6n2e$2ne2$1@digitalmars.com
[3]: http://dlang.org/spec/attribute.html#linkage
[4]: https://github.com/dlang/dmd/blob/v2.074.0/src/ddmd/parse.d#L2148
[5]: https://github.com/dlang/dmd/blob/v2.074.0/src/ddmd/parse.d#L5418
[6]: https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/contextual-keywords

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.

I'd like to congratulate Jared Hanson for a particularly well-written DIP which sets a high standard for how things ought to be done. Well done!

On Saturday, 13 May 2017 at 13:16:40 UTC, Walter Bright wrote:
> 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.
>
> I'd like to congratulate Jared Hanson for a particularly well-written DIP which sets a high standard for how things ought to be done. Well done!

Thank you. Actually, I'd like to ask, are you still as strongly in opposition to making `body` a contextual keyword as you were previously? To me that seems to be the easiest solution, although I am happy going with any of the three proposed solutions.

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. I noticed that you tend
to avoid whitespace when formatting your own code (e.g. [0]) so if '{}{}' was
allowed (in addition to '()()') your code would look even more cryptic
(at least to me) :P

The Phobos style guide, which also mostly matches my personal preference
is to write code like this:

T sqrt(T)(T n)
if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt))
in
{
    assert(n >= 0);
}
out (result)
{
    assert(result * result == n);
}
body
{
    //Implementation
}

If the block is short I sometimes write it like so:

T sqrt(T)(T n)
if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt))
in { assert(n >= 0); }
out (result) { assert(result * result == n); }
body
{
    //Implementation
}

With removal of 'body', the code would look like so:

T sqrt(T)(T n)
if (isNumeric!(Unqual!T) || is(Unqual!T == BigInt))
in { assert(n >= 0); }
out (result) { assert(result * result == n); }
{
    //Implementation
}

Which I actually think looks good.

A small improvement, in addition to omitting 'body' would be to allow
omitting the braces if the 'in' or 'out' blocks contain only a single
statement (similar to 'if', 'foreach', etc.) and to add a similar
syntax sugar alternative for template constraints:

T sqrt(T)(T n)
if Unqual!T U: isNumeric!U || is(U == BigInt)
in n >= 0
out (result) result * result == n
{
    //Implementation
}


[0]:
https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/semantic.d#L845
https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/parser.d#L122
https://github.com/tgehr/d-compiler/blob/175ccb81d6f35feb4fcf3050180ccf6357b4fa51/semantic.d#L131

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(); }

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.

On 13.05.2017 20:26, Eugene Wissner 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(); }
>
> It isn't the same.
> ...

It does not need to be "the same", and I didn't claim it was "the same".
I'm just trying to illustrate why it does not fit into the D grammar. There is no technical point here. "Ugly" does not mean "unreadable" or "broken". It just means it is bad taste. YMMV.

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.