DIP 1003: remove `body` as a keyword

[Basile B. via Digitalmars-d-announce]

On Sunday, 11 December 2016 at 07:52:28 UTC, Rory McGuire wrote:
> On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via 
> Digitalmars-d-announce < digitalmars-d-announce at puremagic.com> 
> wrote:
>
>> On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:
>>
>>> On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:
>>>
>>>> On 11/24/2016 05:29 PM, WM.H wrote:
>>>>
>>>>> On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot 
>>>>> wrote:
>>>>>
>>>>>> DIP 1003 is merged to the queue and open for public 
>>>>>> informal feedback.
>>>>>>
>>>>>> PR: https://github.com/dlang/DIPs/pull/48
>>>>>> Initial merged document:
>>>>>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
>>>>>>
>>>>>> If you want the change to be approved and have ideas how 
>>>>>> to improve it to better match on 
>>>>>> https://github.com/dlang/DIPs/ blob/master/GUIDELINES.md 
>>>>>> and existing published reviews - please submit new PR with 
>>>>>> editorial and ping original author.
>>>>>>
>>>>>
>>>>> This DIP fixes the problem for "body" but not for the other 
>>>>> keywords. After all the problem may exist for other 
>>>>> keywords. Was a new pragma considered ? For example an 
>>>>> identifier alias.
>>>>>
>>>>> pragma(idAlias, "body", "body_" )
>>>>>
>>>>
>>>> AFAIU, the point of this DIP is that "body" is standing out 
>>>> from other keywords being used only in one very specific 
>>>> context and being a very common english word at the same 
>>>> time. Your proposal has a completely different (and much 
>>>> more drastic) approach.
>>>>
>>>
>>> Yes. But while it's clear that "body" is a keyword that's 
>>> less related to programming languages than the others (i.e 
>>> more usable as identifier), it's not actually that mad to 
>>> imagine a generic approach. For example Object Pascal has 
>>> such a feature:
>>>
>>> http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_ 
>>> for_.26-escaping_of_keywords
>>>
>>> which is not well known, as I've myself discovered this just 
>>> 3 minutes
>>> ago.
>>> In D there would be the "#" token that's not really used, 
>>> which could
>>> serve to escape keywords, while still considering them as 
>>> identifier when
>>> it's needed, e.g
>>>
>>> struct Body{}
>>> Body #body;
>>> writeln("'", #body.stringof, "'");
>>>
>>> would output: 'body'
>>>
>>
>> By the way a pragma was a bad idea. Pragmas are optionally 
>> supported by a compiler. An escape symbol is by far better. 
>> Whatever is the compiler we always want the same result.
>>
>> Any chance to get "Cauterite" thoughts on the option that is 
>> to have a token used to escape a keyword, so that the kw can 
>> be used as identifier ?
>>
>> The initial DIP is too specialized, however it shows a real 
>> problem:
>>
>> What if one day someone wants
>>
>>     enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
>>     function Function;
>>
>> With an escape it would always work
>>
>>     enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
>>     #function Function;
>>
>> The problem of the suffix "_", as proposed in D style guide, 
>> is that it's
>> also a valid identifier character, while "#" is not. And the 
>> best is that #
>> role is already for special token sequences !
>> - # = token for special token sequence
>> - body = token
>> => #body is a special token sequence.
>>
>> The only thing to change is that currently a special token 
>> sequence takes a full line...but seriously that's a minor 
>> change (since there's no special token sequence in D... #line 
>> is obsolete and not used anymore).
>>
>
> Why is #line obsolete? I use it a lot in string mixins to make 
> the correct line numbers show.

In the compiler it is. Last Fall I asked and I've got for reply 
that is was useful in the past to debug mixins, in the compiler 
itself. I didn't know that people use it. Anyway it doesn't 
change anything.

DIP 1003 is faddish. It would really be better to have a system 
that would allow any keyword to be used as identifier. An escape 
system is the key.