RFC: DIP draft for "Compiler-defined Attribute Consistency"

[Paul Backus]

On Wednesday, 21 July 2021 at 20:00:32 UTC, Rune Morling wrote:
> In other words, unless I/we can come up with an "algorithm" for 
> deciding when something should be an @-attribute, the DIP I've 
> proposed has little merit in that it's basically just proposing 
> that we shuffle attributes around on a whim.

Here's my take.

D's attributes can be divided, conceptually, into a few different 
"groups" of related attributes. Some examples are:

1. The **Type Constructor Group**: `const`, `immutable`, `inout`, 
and `shared`.
2. The **Inheritance Group**: `final`, `override`, and `abstract`.
3. The **Visibility Group**: `public`, `private`, `protected`, 
`package`, and `export`.
4. The **Function Attribute Group**: `pure`, `nothrow`, `@nogc`, 
`@safe`, `@system`, `@trusted`, `@property`, and `@live`.

...and so on.

The rule I propose is that *within a single group*, use of `@` 
should be consistent--either all of the attributes should use it, 
or none of them should.

Of course this invites some debate as to where exactly one ought 
to draw the group boundaries (e.g., should `@property` be counted 
as part of the function attribute group, or is it a separate 
thing?). But it is at least a step forward from the current 
discussion, which does not even acknowledge that these groups 
exist in the first place.