On 11/21/2016 01:33 PM, Sönke Ludwig wrote:
> For this whole proposal to work out, though, I think the old syntax will have to stay supported without deprecations, because the amount of breakage (the deprecation path won't change that) will otherwise probably be huge. Making "body" optional + contextual seems to be the way to go.

Can you please elaborate on this? Deprecations don't break anything, using -de flag for any stable project is a bug and misuse of compiler. If we define deprecation term for contextual keyword to be several years, the breakage will almost non-existent, much less than a regular "bug fix breakage" from usual releases.

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.

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'

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).

On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via Digitalmars-d-announce < digitalmars-d-announce@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.

Thanks!

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@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.

On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:
> 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@puremagic.com> wrote:
>>
>>>[...]
>>
>> 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.

It would also allow to interface to libs written in another language exporting a D keyword as symbol. I have no example here but I can imagine this happening quite easily.

On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:
> 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.

It would also guarantee that the DIP would not be accepted. With this DIP I aimed for the smallest possible change that would alleviate the problem of not being able to use `body` as a symbol name, hoping that the smallness of the problem and ease of implementation would make it much more likely to be accepted.

On Thursday, 24 November 2016 at 14:06:40 UTC, Jonathan M Davis wrote:
> Personally, I don't care much about having body as a usable symbol. It occasionally would be useful, but I can live without it. However, I _do_ find it very annoying that it's required for the function body when you have contracts. After all, it's not required when you write the function normally. Why should it be required when you have contracts on the function? The braces after the contracts are clearly for the function body. They couldn't be for anything else. The compiler always requires that the body be last after the in and out contracts, making the body keyword totally redundant. So, I've never understood why the body keyword was required. As far as I can tell, it fixes no ambiguity. It's just extra typing, and it makes contracts that much more verbose, which makes me that much more inclined to just not bother with them and put the assertions in the function body - particularly when I'm already of the opinion that they add no value outside of inheritance, because assertions at the beginning of the function take care of in contracts, and unit tests are really what covers the out contract case anyway (particularly since it's very rare that you can have a general test for the out contract rather than testing that specific input results in specific output).
>
> - Jonathan M Davis

General tests of output are not so rare. The premise of property-based testing is being able to write such tests. Going over the functions in std.algorithm, for almost every one of them I can find a nontrivial property that any output should satisfy (for a valid input).

On Sunday, 11 December 2016 at 20:27:36 UTC, Meta wrote:
> On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote:
>> 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.
>
> It would also guarantee that the DIP would not be accepted. With this DIP I aimed

Sorry in a previous post there's been a confusion from my part, I thought the author was "Cauterite".

> for the smallest possible change that would alleviate the problem of not being able to use `body` as a symbol name, hoping that the smallness of the problem and ease of implementation would make it much more likely to be accepted.

I won't insist too much but to be clear, the escape solution is incredibly simple to implement (7 SLOC !). I've decided to go further in order to demonstrate it:

https://github.com/dlang/dmd/pull/6324