DIP 1003 Formal Review

via Digitalmars-d digitalmars-d at puremagic.com
Sat May 13 01:50:10 PDT 2017


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.


More information about the Digitalmars-d mailing list