On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
> the increased visual
> noise definitely is not.

Being able to ignore things starting with @ is useful when reading function signatures:

@property const(T) @pure @nothrow foo(Arg arg, T bar) const ...

So @ can actually be signal rather than noise.

On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:
> Personally, I'd much prefer that we not make this change. It's just
> shuffling things around in an attempt to make them more consistent while
> actually making them _less_ consistent.
>
> - Jonathan M Davis

I don't think this problem is solvable without "dfix". Here are the factors I would consider:

1. `@` is ugly. Therefore it would be great to make `safe`, `trusted`, `system`, and `nogc` full-fledged keywords, to spare future readers of code all those `@`s.  So long as it's definitely a permanent feature of the language, it should look as good as possible. (`property` too, if we're sure it's not leaving). `@` is then left exclusively for UDAs, an improvement, IMO.

2. Consistency of attribute usage is important. All built-in attributes should be markable in the same way, either with, or without an `@` sign.

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

4. Old code matters. Existing code puts points 2 and 3 into conflict.

Now it goes without saying that changing old code is a nuisance. But it's important to point out that not all code changes are the same. In the interest of furthering this discussion, here is a list of the types of breaking changes, in my order of least to most desirable:

B1. Silent breaking changes. Same code now does different things. Rightly regarded as the worst kind. You don't even know what hit you.

B2. Completely pointless changes. For the record, I'm against changes which literally have no benefit. Most changes which get seriously discussed, however, involve difficult tradeoffs, for which the assumed benefit must outweigh the perceived loss, plus the "switching costs". The point of this list is to emphasize that not all switching costs are the same, and that they depend greatly on the *individual* change.

B3. Breaking changes which require significant redesign of code. Sociomantic faces this issue with their move to D2.

B4. Changes which can easily be fixed, with the right know-how. Great error messages, referring the user to the documentation of these changes and how to fix them, is essential.

B5. The kind that a tool such as 'dfix', can automate. For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: `@nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature.

B6. Changes which catch existing bugs, with no false positives. Obviously wins.


The changes suggested in this thread are of kind 5.5. But more people would have to get behind the whole 'dfix' approach for it to work.

"Most D code is yet to be written. #PleaseBreakOurCode." +1

On Monday, 26 January 2015 at 19:02:27 UTC, Zach the Mystic wrote:
> The changes suggested in this thread are of kind 5.5.

s/5.5/B5

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.

For context,

  TV vocabulary - 2,000 words
  High school vocabulary - 10,000 words
  College vocabulary - 30,000 words
  English - 1,000,000 words

i.e. words are NOT a scarce resource (quite unlike punctuation).

On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright 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.
>
> For context,
>
>   TV vocabulary - 2,000 words
>   High school vocabulary - 10,000 words
>   College vocabulary - 30,000 words
>   English - 1,000,000 words
>
> i.e. words are NOT a scarce resource (quite unlike punctuation).

Some words are in high demand, however, like body and match.

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.

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.

Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. 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.

On Mon, Jan 26, 2015 at 11:50:19AM -0800, Walter Bright via Digitalmars-d 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.
> 
> 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.
> 
> Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. 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.

While I generally agree with the sentiment that this great debate over syntax is distracting from more important issues, one particularly attractive point about forcing @ on annotations is that const (as a type qualified) and @const (as a function annotation) become syntactically distinct:

	const int myFunc() @const {}

vs. the current confusing syntax:

	const int myFunc() const {}

Does this alone make it worth it? I'm skeptical. But I thought it should be pointed out regardless.


T

-- 
If it tastes good, it's probably bad for you.

On Mon, 26 Jan 2015 19:46:21 +0000, Meta wrote:

> On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright 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.
>>
>> For context,
>>
>>   TV vocabulary - 2,000 words High school vocabulary - 10,000 words
>>   College vocabulary - 30,000 words English - 1,000,000 words
>>
>> i.e. words are NOT a scarce resource (quite unlike punctuation).
> 
> Some words are in high demand, however, like body and match.

body will not be "dekeyworded".

Walter Bright  2014-02-12 14:44:20 UTC In hindsight, the choice of 'body' for the keyword is unfortunate. But fixing it would cause even worse problems, so I think we're stuck with it.

nobody told us what "worse problems" are. using "body" is not confusing, lowering it into identifier will not break any code, but... "worse problems" awaits.

i'm using patch that allows "body" as identifier for almost a year, i'm constantly building alot of projects from dub repo, and i haven't encountered any problems with it. but i believe that i'm simply doing something wrong and dragons are around the corner.

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.

"5. The kind that a tool such as 'dfix', can automate. For
example, let's say dfix is included with the compiler package.
Now you get an error, saying: "Error: `@nogc` is no longer
accepted, but can be automatically replaced with `nogc`. Run dfix
on this file? (y/n)"... or whatever is deemed the secure approach
to this feature.
"

Sorry for the tangent (I have no view on the major topic),  +1 for including a link to dfix within the compiler.  Repetitive things ought to be automated and made easy and how many times does one end up fixing up old code ?