On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler wrote:
> On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
>> 3. Singularity of usage also matters. There should only be one
>> way to mark a given attribute, either with or without `@`.
>
> 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?

The consistency issue is precisely that there should not be more than one way to write an attribute. Note that that's precisely where most of the opposition to this thread's original proposal came from. Uniformity means never having to explain to anybody why there is more than one way to do something. Both this thread's proposal and your proposal *introduce* inconsistency in this way.

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

This will annoy people even more than they are already annoyed by the `@`-on-some-attributes-and-not-others inconsistency. The latter type (type 2 in my first thread) already exists in the language, but it shoudln't be replaced by another type. This argument was already made by Jonathan Davis.

On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic wrote:
> On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler wrote:
>> On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
>>> 3. Singularity of usage also matters. There should only be one
>>> way to mark a given attribute, either with or without `@`.
>>
>> 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?
>
> The consistency issue is precisely that there should not be more than one way to write an attribute. Note that that's precisely where most of the opposition to this thread's original proposal came from. Uniformity means never having to explain to anybody why there is more than one way to do something. Both this thread's proposal and your proposal *introduce* inconsistency in this way.
>
>> 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.
>
> This will annoy people even more than they are already annoyed by the `@`-on-some-attributes-and-not-others inconsistency. The latter type (type 2 in my first thread) already exists in the language, but it shoudln't be replaced by another type. This argument was already made by Jonathan Davis.

Yes you're right it adds more inconsistency (sorry what I said was wrong).  However, no matter what solution you choose you have to choose one of two evils.  Either add inconsistency or break code.  There's no way around it.  If you ADD another way to write the attributes that looks better, you've created more "inconsistency".  If you REPLACE the existing way to write attributes, you've now broken code.

I proposed that we ADD another way of writing attributes, however, my proposal doesn't require that we ADD another way, instead, we can REPLACE the current way of writing attributes by normalizing where they appear.  However, like I said, you have to choose one or the other, broken code or inconsistency.

The nice part about ADDING another way of writing attributes is that the hope is that the inconsistency will be solved in the future.  Changing the way to write attributes will introduce more inconsistency at first.  However, the hope is that if the new way is "better" or looks "nicer", then developers will hopefully consistently choose the new way. Then, if there's no reason to keep the old way, it can be deprecated and the consistency issue is solved.

So again, I was suggesting one way of implementing my proposal which was to add an inconsistency, but you could implement it another way but you would have to break code.  Do you have a solution that doesn't do either?  I think if you try to find one, you'll see that I'm right in saying you're going to have to choose one or the other.

On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:
> On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
>> Personally, I'd much prefer that we not make this change.
>
> It's good to have this discussion.
>
> Previously, it's all been advocacy and "break my code" by forcing a change from pure => @pure.

Yes, please! (at least about the "break my code" part)

>
> Just a few days ago on slashdot, an anonymous D user wrote:
>
>   "A horrible mix of keywords and annotation syntax for function/method
>   attributes ('const', 'pure', and 'nothrow' are all keywords, but
>   '@property', and '@nogc' are annotations)"
>
> for why he won't use D anymore.

Not a deal-breaker for me, but I agree with the sentiment, and I think it makes for a more professional language if such inconsistencies are addressed.

>
> Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important.

Yes, there is no correlation between what's important, and what people choose to work on, because there is no consensus on what's important, and if there is it's usually beyond the ability of most contributors, so it doesn't get worked on anyway.  Personally, I find small changes like this welcome because they make for a more polished experience.

> I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.

A dangerous precedent.  I suspect the push-back against this change has probably ruined any chance of further polishing the language.

From: https://issues.dlang.org/show_bug.cgi?id=13388#c27
***
>> I really think that we've passed the point where it's worth fixing it.

NO!!!! This attitude is the biggest problem D has.
Please, watch Scott Meyer's talk again. "Most D code is yet to be written".
The future benefits of fixing this kind of crap, are huge.
***

In fact, it is the attitude against change that has put me on the fence about D, when I was quite an advocate about a year ago.  It has also made me reluctant to put forth the necessary effort to study and make any significant contributions because the controversy, as exhibited here, would likely erase my entire investment.  Instead, I have begun exploring other options while keeping one foot on the raft.

I agree that, in general, D should take a more disciplined approach to development, but keep in mind that if contributors have to go through too much controversy and bureaucracy we're not going to see much change (perhaps that's what some want).

I feel for Walter.  He's damned if he does and damned if he doesn't.  Somehow, this herd of cats need to figure out where it wants to go, and I need to figure out whether to go all in or jump ship.

Mike

On Tuesday, 27 January 2015 at 01:32:23 UTC, Mike wrote:
> On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:
>> On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
>>> Personally, I'd much prefer that we not make this change.
>>
>> It's good to have this discussion.
>>
>> Previously, it's all been advocacy and "break my code" by forcing a change from pure => @pure.
>
> Yes, please! (at least about the "break my code" part)
>
>>
>> Just a few days ago on slashdot, an anonymous D user wrote:
>>
>>  "A horrible mix of keywords and annotation syntax for function/method
>>  attributes ('const', 'pure', and 'nothrow' are all keywords, but
>>  '@property', and '@nogc' are annotations)"
>>
>> for why he won't use D anymore.
>
> Not a deal-breaker for me, but I agree with the sentiment, and I think it makes for a more professional language if such inconsistencies are addressed.
>
>>
>> Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important.
>
> Yes, there is no correlation between what's important, and what people choose to work on, because there is no consensus on what's important, and if there is it's usually beyond the ability of most contributors, so it doesn't get worked on anyway.  Personally, I find small changes like this welcome because they make for a more polished experience.
>
>> I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.
>
> A dangerous precedent.  I suspect the push-back against this change has probably ruined any chance of further polishing the language.
>
> From: https://issues.dlang.org/show_bug.cgi?id=13388#c27
> ***
>>> I really think that we've passed the point where it's worth fixing it.
>
> NO!!!! This attitude is the biggest problem D has.
> Please, watch Scott Meyer's talk again. "Most D code is yet to be written".
> The future benefits of fixing this kind of crap, are huge.
> ***
>
> In fact, it is the attitude against change that has put me on the fence about D, when I was quite an advocate about a year ago.  It has also made me reluctant to put forth the necessary effort to study and make any significant contributions because the controversy, as exhibited here, would likely erase my entire investment.  Instead, I have begun exploring other options while keeping one foot on the raft.
>
> I agree that, in general, D should take a more disciplined approach to development, but keep in mind that if contributors have to go through too much controversy and bureaucracy we're not going to see much change (perhaps that's what some want).
>
> I feel for Walter.  He's damned if he does and damned if he doesn't.  Somehow, this herd of cats need to figure out where it wants to go, and I need to figure out whether to go all in or jump ship.
>
> Mike

+1 to all of this as it mirrors exactly how I feel about D at this point in time.

I get the impression it will never be finished because too many are afraid of important breaking changes that seem necessary to get through the last 5%-10% of D2.

Cheers,
uri

On 1/26/2015 5:45 PM, uri wrote:
> I get the impression it will never be finished because too many are afraid of
> important breaking changes that seem necessary to get through the last 5%-10% of
> D2.

Half want breaking changes, the other half wants stability.

On 1/26/2015 2:57 PM, Mike wrote:
> 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.

It's the continuous drip-drip-drip of this that ticks people off.

On 01/26/15 23:10, Walter Bright via Digitalmars-d wrote:
> On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:
>>> Just 'no' on context-sensitive tokens.
>> C. C++. D. Windows. Pascal. System. exit. success. failure.
> 
> They're never keywords.

Hence, some other ones also don't really need to be keywords.

Note I'm not arguing for/against these changes; just pointing out that there's precedent, as context sensitive magic identifiers already exist in D. Whether you want to call them "tokens" doesn't really matter (it's just an implementation detail). I actually would have preferred that they don't exist, but they do.

artur

On 1/26/2015 3:07 PM, Jonathan Marler wrote:
> 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.

Your argument boils down to there are no such things as token keywords. Yes, you can make a language work like that. I've seen it done. It is awful. The solution is clear:

   static is a keyword. You can NEVER use it as an identifier. Same with all other keywords.

On 1/26/2015 2:15 PM, Foo wrote:
> 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.

Major contributors to D, like Don Clugston, advocated for it.

It comes up repeatedly.

On Tuesday, 27 January 2015 at 01:55:30 UTC, Walter Bright wrote:
> On 1/26/2015 3:07 PM, Jonathan Marler wrote:
>> 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.
>
> Your argument boils down to there are no such things as token keywords. Yes, you can make a language work like that. I've seen it done. It is awful. The solution is clear:
>
>    static is a keyword. You can NEVER use it as an identifier. Same with all other keywords.

This has become quite frustrating.  I'm not sure how else to explain myself so maybe I'm just being dumb. Something inside me wants to explain myself again so I'll try one more time, if this fails, then it must be me not understanding your explanation and I'll give up. My proposal has nothing to do with keywords, it can be summarized with the following 2 steps:

1. Change the syntax of a function to allow it to be decorated with general id tokens.

2. Modify code generation to look at these new tokens and treat them as function attributes.

I would suggest only allowing these id tokens to appear after the function arguments so as not to introduces any ambiguity in the grammar.

void myfunc() pure safe nothrow nogc;

 pure (still a keyword, no change)
 safe (still NOT a keyword, no change)
 nothrow (stil a keyword, no change)
 nogc (still NOT a keyword, no change)

My proposal is not trying making tokens "context-sensitive" by treating them as keywords sometimes and identifiers at other times.  All it is doing is allowing an identifer token to be used as a function attribute.  Nothing to do with keywords.