DIP 1012--Attributes--Preliminary Review Round 1

[Nick Treleaven via Digitalmars-d]

On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
> Should public have @ on it? Should static have @ on it? What 
> about scope, const, or shared?

If they are storage classes, they shouldn't have @. If they are 
statement or expression keywords, they shouldn't have @. Things 
like that are introduced with leading underscores: __traits, 
__gshared.

public etc could be @ attributes, but I see no reason to change 
them. This inconsistency can be explained by just saying 
visibility is special. (That said I wouldn't complain if they 
were changed too). Common keywords in other languages can help 
justify keeping those keywords in D.

> it looks like the DIP is talking about what the default 
> attributes in general are. It's one thing to slap a default set 
> of attributes at the top of a module and then negate them later 
> in the module

This is one part of the DIP I like - `@safe module foo;`. AIUI 
this would enable a @safe default that doesn't stop code such as 
templates being inferred as @system. This is not currently 
possible in D. I know Walter has talked about inferring 
attributes for all function bodies - in that case the DIP seems a 
bit less useful, but could still set the default for unittests, 
module ctors/dtors and main().