On 1/26/2015 1:29 PM, Dicebot wrote:
> However my complaint is not about the change itself (though I personally
> disagree with Don reasoning in that issue, it is a delicate matter) but about
> the fact that it is again done as a casual PR and our breaking change culture
> does not seem to change : it is still all or nothing approach. No automatic
> migration tools, no easily found rationale / explanation, no posts in D.announce
> - just an ordinary commit. No wonder any of more notable change is considered
> that scary.

What I wanted by doing this is to produce some sort of consensus. The topic has already been discussed to death.

Examples:

[1]: https://github.com/D-Programming-Language/druntime/blob/2024ca6d3e29362a2fc84ef51c0f73316259d645/src/core/internal/traits.d#L57

[2]: https://github.com/D-Programming-Language/phobos/blob/de5d3392782c85e79e71e257b3ba607ccff852a5/std/typecons.d#L3240

On Monday, 26 January 2015 at 22:02:44 UTC, ZombineDev wrote:
> That's what pragma(mangle, "...")[1] is for. It is used at least a couple of times in druntime (and probably elsewhere - e.g. in library bindings).
>
> [1]: http://dlang.org/pragma.html (at the bottom of the page)
>
>
> On Monday, 26 January 2015 at 21:56:20 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
>>> I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?
>>
>> There is no ambiguity in "object.body" or even "object.if = 42"... All you need is an escape mechanism in the definition.
>>
>> The reason for why you want this is that you interoperate with external interfacing definitions and standards that you auto generate D code from. It is not likely that the external world (like governments who define record exchange standards) will adapt their naming policies to D idiocracies.
>>
>> If you cannot use "body" as a field name then you cannot implement the HTML5 DOM according to the standard.

On 1/26/2015 1:25 PM, Jonathan Marler wrote:
> The lexer would recognize these attributes as normal ID tokens. The grammar
> could be amended to allow a function to be decorated with keywords and generic
> id tokens.  Then the meaning of those tokens would be handled by semantic
> analysis.

Not going to do that.

> So the result would be that the lexer would see "nogc" and "safe" as
> normal id tokens (not keywords) which would be consumed as function attributes
> by the grammar.  As far as I can tell this results in the best of both worlds.
> We can omit the '@' character on function attributes like safe and nogc but they
> don't have to be added as keywords.

I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis.

It's like using a nail for a cotter pin.

On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:
> C. C++. D. Windows. Pascal. System. exit. success. failure.


They're never keywords.

On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote:
> On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote:
>> On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:
>>> On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:
>>>> On 1/26/2015 12:45 PM, Jonathan Marler wrote:
>>>>> Just because they are function attributes does not mean
>>>>> they were tokenized as "keywords".
>>>>
>>>> The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
>>>
>>> I feel like I keep repeating myself so I'm just going to copy/paste.
>>>
>>>> If the grammar supported decorating a function with a list of id
>>> tokens (not just keywords), then you could implement a variation
>>> on the c++ solution of allowing "override" and "final" after a
>>> function signature.
>>>
>>> The lexer would recognize these attributes as normal ID tokens.
>>> The grammar could be amended to allow a function to be decorated with keywords and generic id tokens.  Then the meaning of those tokens would be handled by semantic analysis.
>>> So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar.  As far as I can tell this results in the best of both worlds.  We can omit the '@' character on function attributes like safe and nogc but they don't have to be added as keywords.
>>
>> Right. That's was what I meant.
>> Same thing could be possible for body...
>
> Ya same thing applies to "body".  I'm surprised no one has given a reason why it wasn't done this way.

Because you/we are community members and therefore "second-class citizens".
If we suggest or discuss something, it is not that important. But if a small reddit post is made, it matters more.
Look what happend to auto ref for non templates: community wants it but we don't get it.

On 26.01.15 23:08, Walter Bright wrote:
> 
> I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis.
> 
> It's like using a nail for a cotter pin.

I remember the first time I read about D was something like "make language easier for compiler". It attracted me. (OK not only this :)

On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:

> if we deprecate pure and nothrow without @, then we'll be
> forced to change pretty much every D program in existence.
>

A trivial search and replace.  Some might be against this change now, but 5 years from we'll profit from it.

Mike

On Monday, 26 January 2015 at 22:09:44 UTC, Walter Bright wrote:
> On 1/26/2015 1:25 PM, Jonathan Marler wrote:
>> The lexer would recognize these attributes as normal ID tokens. The grammar
>> could be amended to allow a function to be decorated with keywords and generic
>> id tokens.  Then the meaning of those tokens would be handled by semantic
>> analysis.
>
> Not going to do that.
>
>> So the result would be that the lexer would see "nogc" and "safe" as
>> normal id tokens (not keywords) which would be consumed as function attributes
>> by the grammar.  As far as I can tell this results in the best of both worlds.
>> We can omit the '@' character on function attributes like safe and nogc but they
>> don't have to be added as keywords.
>
> I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis.
>
> It's like using a nail for a cotter pin.
Walter I hate to waste your time in answering my silly questions.  I know you have a much deeper knowledge and understanding of the language then I.  I can see that you believe my suggestion would create some unnecessary complexity ("It's like using a nail for a cotter pin"), however, I can't see how it would so I'm going to ask another question. I can see that you are trying to save time from your short responses so I'll understand if I understand if you feel I'm a lost cause and do not respond again.

You said you strongly dislike "context-sensitive" tokens but I still don't know exactly what you mean by "context-sensitive".  You said a token is "context-sensitive" if it is "A keyword in one context and an identifier in another".  However, since I'm not proposing that "save" and "nogc" be keywords in any context, this doesn't appear to fall under your definition.  So I must assume your real definition is more general. However, if the definition is too general then couldn't you consider almost any token "context-sensitive".  For example, the token "static" or "ref" have different meanings depending on their context, so are they "context-sensitive"?  Yes they are still keyword tokens, but "safe" and "nogc" would still just be regular id tokens so what makes "safe" and "nogc" more "context-sensitive" then "static" and "ref"?

I'm honestly trying to understand.  I can see from how the grammar works that you don't agree my solution is a good one, but I'm failing to understand why.  I fail to see how allowing a function to be decorated with id tokens is more complex then only allowing keywords.  Also sorry for harping on definitions,  I majored in Computer Science and Mathematics...having strict definitions comes from my days of writing endless proofs.

On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
> If someone is not following the merges, well...  [1] !!
>
> ---
> Paolo
>
> [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail

In case anybody was wondering, dfix has had the ability to do the "nothrow" -> "@nothrow" conversion since October.

On Monday, 26 January 2015 at 22:04:48 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:
>>> I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?
>>
>> I wasn't saying that we should introduce ambiguity, I was saying we should be careful not to introduce ambiguity.  I wrote that to indicate that I wasn't sure if the solution would introduce ambiguity or not.  Zach suggested a solution that I'm
>
> I think you meant someone else!
>
>> fairly certain would be unambiguous (it's nice to have c++ people who've already seen the same problem know of a solution).  By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate.
>>  However, allowing the attributes to appear before the function signature *might* work, but that would require much more care and may not even be possible (like I said, I'm not sure).
>
> I don't think it is possible. Any non-keyword identifier is assumed to be the return type of the function. It all has to be solved in the parsing phase. You can't wait till semantic analysis to figure out what's a return type and what's an attribute. This is why D compiles so fast, because all phases of compilation are distinct.

Copy/Paste:

>> solution).  By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate.

The return type doesn't appear after the function signature.