DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 11:45:21 UTC, Nick Treleaven wrote:
> 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.

the only catch there is that the `package` visibility takes an 
optional module following it and therefore can't be done as an 
enum.

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

Hmm, after some discussions in this thread I decided that it 
would be better to have a "last applied wins" rule so as not to 
need the whole tag the module decl to set the default for the 
module. I suppose it could be bought back if need be but it's 
kind of redundant with "last applied wins". Templates may still 
be a bit of a problem.