DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

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