On Thursday, 27 July 2017 at 15:40:01 UTC, jmh530 wrote:
On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote:
_Why_ it works like that I have no idea.
I thought that the attributes were just using the same behavior
as public/private/etc.
Anyway, isn't that the same type of behavior this DIP is
suggesting? There is an @nogc module foo; example in the DIP
that has a gc function included and doesn't say anything about
it being an error.
The DIP has a list of attributes not encompassed, but there are
missing attributes from [1]. For instance, the visibility
attributes are not encompassed, but that is not mentioned. In
this case, they are grouped and have a default (public) and an
opposite (private). However, it would break a lot of code to
force them to use @. Might be useful to mention why not
included.
https://dlang.org/spec/attribute.html
Hmm. With private/package/protected/public/export you can mix
and match them as you please:
public:
void foo() {}
void bar() {}
private:
void baz() {}
int a,b;
public int c;
whereas if it were to be encompassed by this DIP that would no
longer work. Maybe it should work, perhaps a last attribute wins
(assuming previous `@attributes:` come before it in the list)?
Might be useful to mention why not included.
This DIP focuses on function (i.e. @-like attributes), the rest
of those attributes are storage classes/visibility classes or
parametric in a way that doesn't fit with this DIP (extern(C++,
A.B), package(foo) align(N).
