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

On Fri, May 12, 2017 at 04:17:03PM +0000, Mike Parker via Digitalmars-d 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

I vote for Option 3: make `body` an optional keyword for a release, then deprecate it for another release, then Kill It With Fire. I completely agree with the rationale stated in the DIP, that `body` is a commonly used identifier and therefore should not be a keyword; but even more so that `body` serves little purpose in the language because it is used only in *one* context, and in that context it's not even strictly necessary as no grammar ambiguity would arise from removing it.

I disagree that `function` is not overloaded: it *will* be overloaded if option 2 is chosen, because `function` currently means function *pointer*, not the function body itself.  For this reason, I oppose Option 2.

I also dislike option 1 because contextual keywords represent incongruity in the language, and lately I've come to the conclusion that incongruities will ultimately become inhibitors of progress and sources of problems. (There is more to it than that, but this subject in its generality is OT here so I'll just leave it at that.)  Furthermore, as I've said, `body` is not even necessary in the single, only context in which it's used.  It does not serve to disambiguate anything, because no grammar ambiguity would result from its absence.  So I regard it something completely redundant that the language would do better without.

Even though option 3 entails eventual code breakage, I for one would welcome that because it would reduce the amount of unnecessary syntax in my code.

A possible compromise could be to make `body` both contextual and optional, so that no existing code will break, but new code also can be freed from the unnecessary syntactic noise and the identifier `body` can be freed up for user use.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

On 05/12/2017 09:17 AM, 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 3.

Ali

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/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>
> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org
Option 3. just write //body
or /* body */ if you still want to mark the block.

On 5/12/17 12:17 PM, 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

All seems good to me. I could go with Option 1 or 3. Option 2 seems unnecessary.

-Steve

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/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>
> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org

3

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/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>
> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org

3

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/fbb797f61ac92300eda1d63202157cd2a30ba555/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();

And also let's not forget that 'in' and 'out' are both parameter storage classes and keywords in the context of contracts.

This has never been a problem for D and other languages are doing great with this feature:

https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/contextual-keywords

C# also has a way of using identifiers with the same name as reserved keywords:
https://github.com/dotnet/csharplang/blob/master/spec/lexical-structure.md#identifiers
(as far as I remember Basile tried to implement this, but ran into some problems, so I'm not sure how doable is such a feature for D, in the presence of mixins).

Even if for this particular case contextual keywords are not the best solution (I disagree), I believe that dismissing them would be mistake. They are a powerful technique in language design that allows evolution of the language without the issues with associated with changing the meaning of / breaking existing user code.

On Saturday, 13 May 2017 at 08:50:10 UTC, Petar Kirov [ZombineDev] 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/fbb797f61ac92300eda1d63202157cd2a30ba555/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();
>
> And also let's not forget that 'in' and 'out' are both parameter storage classes and keywords in the context of contracts.
>
> This has never been a problem for D and other languages are doing great with this feature:
>
> https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/contextual-keywords
>
> C# also has a way of using identifiers with the same name as reserved keywords:
> https://github.com/dotnet/csharplang/blob/master/spec/lexical-structure.md#identifiers
> (as far as I remember Basile tried to implement this, but ran into some problems, so I'm not sure how doable is such a feature for D, in the presence of mixins).
>
> Even if for this particular case contextual keywords are not the best solution (I disagree), I believe that dismissing them would be mistake. They are a powerful technique in language design that allows evolution of the language without the issues with associated with changing the meaning of / breaking existing user code.

Correction: 'in' and 'out' are not contextual keywords, they are an example of giving keywords different meanings in different contexts, just like 'static'. AFAIK, you can't use them for identifiers, like 'C' - think 'extern (C)'.

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.





[1] Also, here is a list of existing contextual keywords:

exit
success
failure
C
C++
D
Windows
Pascal
System
Objective-C