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.
