On Monday, 26 January 2015 at 21:25:57 UTC, 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.

How do you tell the difference between a return type and a user attribute on the left side?

nogc myUda1 myUda2 returnType funcName() { return returnType(a); }

They are UDAs only because they are not the second-to-last id (the return type) or the last id (the function name). How do you do 'auto' inferred return types in this context, when the compiler thinks your UDA is also your return type? Also, why burden the *programmer* with having to sort this out? It's too ambiguous to read, for my taste. If I just switch the names the entire signature changes:

nogc returnType myUda1 myUda2 funcName() { return returnType(a); }

Now it's supposed to return a myUda2, just because you switched the ordering? I can see why this idea would be rejected.

On Monday, 26 January 2015 at 23:41:07 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 21:25:57 UTC, 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.
>
> How do you tell the difference between a return type and a user attribute on the left side?
>
> nogc myUda1 myUda2 returnType funcName() { return returnType(a); }
>
> They are UDAs only because they are not the second-to-last id (the return type) or the last id (the function name). How do you do 'auto' inferred return types in this context, when the compiler thinks your UDA is also your return type? Also, why burden the *programmer* with having to sort this out? It's too ambiguous to read, for my taste. If I just switch the names the entire signature changes:
>
> nogc returnType myUda1 myUda2 funcName() { return returnType(a); }
>
> Now it's supposed to return a myUda2, just because you switched the ordering? I can see why this idea would be rejected.

I wasn't proposing UDA's to omit the '@', only LDA's (Language defined attributes).  Also, again, your example is assuming that we allow identifiers before the function signature, which is on optional part of what I proposed.  The bigger problem with that proposal would be that if a function can start with a list of general id tokens, it's very likely to create ambiguity in the grammar.  However, if they can only appear after the function signature, I'm almost certain no ambiguity is created.  There are different ways to get around this, one is to require the '@' only if the attribute appears before the function signature.  The other is to disallow function attributes before the signature (or at least certain ones).  There's different solutions, but that's not the point of the proposal.  The point of the proposal is to

  Allow a function to be decorated with id tokens (so long as it doesn't create ambiguity) in order to specify attribute like "safe"/"nogc"/etc

There are different ways to implement this and I see people arguing about specific implementations, but no one is addressing the main concept of the proposal (except Walter who just says that he doesn't like "context-sensitive" tokens but I fail to see how this creates tokens that are more "context-sensitive" then other tokens)

On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler wrote:
> 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.

Yes it *is* another debate. Now you can't add attributes at the beginning:

// no can do anymore
nogc pure myUda
retType funcName() {
   ...
}

// must do this instead
retType funcName() nogc pure myUdal {
}

You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.

On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler wrote:
>> 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.
>
> Yes it *is* another debate. Now you can't add attributes at the beginning:
>
> // no can do anymore
> nogc pure myUda
> retType funcName() {
>    ...
> }
>
> // must do this instead
> retType funcName() nogc pure myUdal {
> }
>
> You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.

http://en.wikipedia.org/wiki/Straw_man

I'm not proposing that we don't allow attributes before a function, I was mentioning an idea related to my proposal.  I agree with everything you said, you're just not addressing the proposal itself (see the link).

On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:
> Yes it *is* another debate. Now you can't add attributes at the beginning:
>
> // no can do anymore
> nogc pure myUda
> retType funcName() {
>    ...
> }
>
> // must do this instead
> retType funcName() nogc pure myUdal {
> }
>
> You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.

Also, aren't attribute blocks made impossible by this?:

nogc:

auto myFunc() { ... }
auto myOtherFunc() { ... }

On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler wrote:
> http://en.wikipedia.org/wiki/Straw_man
>
> I'm not proposing that we don't allow attributes before a function, I was mentioning an idea related to my proposal.  I agree with everything you said, you're just not addressing the proposal itself (see the link).

Show code examples of how it would work. I can't guess anymore what you're proposing.

On Monday, 26 January 2015 at 20:26:02 UTC, Dicebot wrote:
> It was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to.
>
> Please, revert this PR asap. After that it can possibly be introduced after meeting necessary prerequisites:
>
> 1) explanation of problem it fixes
> 2) design rationale for new model
> 3) evaluation of ROI
> 4) tools for simple migration - either as part of dfix or compiler
>
> This is absolutely mandatory list for any change of language fundamentals to be considered legitimate.

+1, and I doubt the ROI analysis will come positive.

On Monday, 26 January 2015 at 23:55:55 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler wrote:
>> http://en.wikipedia.org/wiki/Straw_man
>>
>> I'm not proposing that we don't allow attributes before a function, I was mentioning an idea related to my proposal.  I agree with everything you said, you're just not addressing the proposal itself (see the link).
>
> Show code examples of how it would work. I can't guess anymore what you're proposing.

Haha, ok, sorry for being too abstract.

I think a safe way to implement my proposal would be to do what c++ did and only allow non-keyword function attributes to omit the '@' symbol if they appear after the function signature:

Here's what would change
-----------------------------------------------------------------
void myfunc() nogc; // VALID (Only if this proposal is accepted)
void myfunc() safe; // VALID (Only if this proposal is accepted)


Here's what WOULD NOT change
-----------------------------------------------------------------
nogc myfunc(); // STILL INVALID: invalid unless it can be verified
               //          that this wouldn't result in ambiguity
               //          in the grammar
void myfunc() @nogc; // STILL VALID (no change)
@nogc myfunc(); // STILL VALID (no change)

If the initial proposal is accepted by people, then we can talk about the other examples, but let's focus on the proposal before focusing on sub-proposals.

On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler wrote:
> Haha, ok, sorry for being too abstract.
>
> I think a safe way to implement my proposal would be to do what c++ did and only allow non-keyword function attributes to omit the '@' symbol if they appear after the function signature:
>
> Here's what would change
> -----------------------------------------------------------------
> void myfunc() nogc; // VALID (Only if this proposal is accepted)
> void myfunc() safe; // VALID (Only if this proposal is accepted)
>
>
> Here's what WOULD NOT change
> -----------------------------------------------------------------
> nogc myfunc(); // STILL INVALID: invalid unless it can be verified
>                //          that this wouldn't result in ambiguity
>                //          in the grammar
> void myfunc() @nogc; // STILL VALID (no change)
> @nogc myfunc(); // STILL VALID (no change)
>
> If the initial proposal is accepted by people, then we can talk about the other examples, but let's focus on the proposal before focusing on sub-proposals.

Alright, good. However... I'm still against it. Firstly, in my first comment in the current thread,

http://forum.dlang.org/post/uimpnhiweuitnnbeqshu@forum.dlang.org

...I made a list of considerations, among which:

3. Singularity of usage also matters. There should only be one
way to mark a given attribute, either with or without `@`.

This alone puts me at next to zero for your proposal in terms of benefit. It will strike people as a strange and unnecessary exception to the way to mark their attributes, for the sake of a slight beautification of only those cases where the attributes come after the signature. Consider me an old-fashioned "a keyword is a keyword is a keyword" kind of guy. Yes, there are outliers (C++, D, exit, success, etc.), but I don't see why that list should be expanded, as it is nicely contained, IMO.

On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic wrote:
> On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler wrote:
>> Haha, ok, sorry for being too abstract.
>>
>> I think a safe way to implement my proposal would be to do what c++ did and only allow non-keyword function attributes to omit the '@' symbol if they appear after the function signature:
>>
>> Here's what would change
>> -----------------------------------------------------------------
>> void myfunc() nogc; // VALID (Only if this proposal is accepted)
>> void myfunc() safe; // VALID (Only if this proposal is accepted)
>>
>>
>> Here's what WOULD NOT change
>> -----------------------------------------------------------------
>> nogc myfunc(); // STILL INVALID: invalid unless it can be verified
>>               //          that this wouldn't result in ambiguity
>>               //          in the grammar
>> void myfunc() @nogc; // STILL VALID (no change)
>> @nogc myfunc(); // STILL VALID (no change)
>>
>> If the initial proposal is accepted by people, then we can talk about the other examples, but let's focus on the proposal before focusing on sub-proposals.
>
> Alright, good. However... I'm still against it. Firstly, in my first comment in the current thread,
>
> http://forum.dlang.org/post/uimpnhiweuitnnbeqshu@forum.dlang.org
>
> ...I made a list of considerations, among which:
>
> 3. Singularity of usage also matters. There should only be one
> way to mark a given attribute, either with or without `@`.
>
> This alone puts me at next to zero for your proposal in terms of benefit. It will strike people as a strange and unnecessary exception to the way to mark their attributes, for the sake of a slight beautification of only those cases where the attributes come after the signature. Consider me an old-fashioned "a keyword is a keyword is a keyword" kind of guy. Yes, there are outliers (C++, D, exit, success, etc.), but I don't see why that list should be expanded, as it is nicely contained, IMO.

I agree that the proposal doesn't solve the consistency issue, but the proposal doesn't make things more inconsistent then they already are. It adds another way to write these attributes, but it adds a way that makes more sense in my opinion.  This is a step in the right direction in solving the problem.  The next step would be to solve the consistency issue, but again, that's another debate. To conclude, which code would you rather write?

void myfunc() pure @safe nothrow @nogc;
void myfunc() pure safe nothrow nogc;

This will inevitably result in someone writing this:

pure safe nothrow nogc void myfunc();

which would still be invalid in this proposal, and I think this is still a problem but not a huge one since this is easily caught by the compiler.