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