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.

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

On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
> I agree with Jonathan's points, this solution doesn't seem like an improvement.   If I understand the problem, we don't want to make every attribute use the '@' symbol because it looks bad and would cause a lot of code changes for sake of consistency.  However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...).
>
> Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords?  Then we can omit the '@' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords.
>
> I understand that doing this may be fairly complicated.  This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.

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?

On Monday, 26 January 2015 at 21:17:50 UTC, Walter Bright wrote:
>> Donno If you are referring to this [1], but at least it's about this pull...
>> [1]
>> http://forum.dlang.org/thread/bug-13388-3@https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.com
>
> Yup, that's it. Your search-foo is better than mine!
>
> A more direct link:
>
> https://issues.dlang.org/show_bug.cgi?id=13388#c27

I was referring to earlier posts (as old as Don's dconf 2013 talk ;))

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.

On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
>> I agree with Jonathan's points, this solution doesn't seem like an improvement.   If I understand the problem, we don't want to make every attribute use the '@' symbol because it looks bad and would cause a lot of code changes for sake of consistency.  However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...).
>>
>> Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords?  Then we can omit the '@' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords.
>>
>> I understand that doing this may be fairly complicated.  This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.
>
> 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 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).  A comprimize could be to allow attributes to omit the '@' character if they appear after the function signature and require the '@' character if they appear before.  I'm not saying that's a good idea, just an option.

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.

On 01/26/15 20:43, Walter Bright via Digitalmars-d wrote:
> On 1/26/2015 8:13 AM, Foo wrote:
>> You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.
> 
> Just 'no' on context-sensitive tokens.

C. C++. D. Windows. Pascal. System. exit. success. failure.

artur

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.

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