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

On Thursday, 27 July 2017 at 15:48:04 UTC, Olivier FAURE wrote:
> On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
>> DIP 1012 is titled "Attributes".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
>
> This DIP proposes a very complex change (treating attributes as Enums), but doesn't really provide a rationale for these changes.

It is actually a very simple change, from the end user perspective.
* Function attributes that were keyword like, become regular attributes.
* They can be applied to modules, acting as a default for applicable symbols in the module.

On Thursday, 27 July 2017 at 17:35:34 UTC, Adrian Matoga wrote:
> I don't want to see monsters like "@core.attribute.GarbageCollectedness.inferred" as part of any declaration, ever.
> I agree that the problem is valid, but I don't think adding the complexity and verboseness presented in the DIP can solve it.

You almost certainly won't, although "@core.attribute.GarbageCollectedness.inferred" would still be valid. GarbageCollectedness.inferred is a regular attribute and can be aliased to whatever you want, put in an AliasSeq or hidden behind some template that generates a whole bunch of attributes.

On Thursday, 27 July 2017 at 16:56:14 UTC, ketmar wrote:
> Mike Parker wrote:
>
>> DIP 1012 is titled "Attributes".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> didn't get the rationale of the DIP at all. the only important case -- attribute cancelation -- is either missing, or so well-hidden that i didn't found it (except fast mention). everything other looks like atronautical complexity for the sake of having some "abstract good" (that is, for all my years of using D as the only lanugage i'm writing code into, i never had any need to "group defaults" or something -- only to selectively cancel attrs).
>
> tl;dr: ketmar absolutely didn't got what this DIP is about.

Hmm, maybe a "last applied wins" could work, although this may require some complex changes to the compiler if the order that attributes apply is unspecified.

As in reply to a sibling comment the change is very simple: keyword- like function attributes instead become regular attributes.

On Thursday, 27 July 2017 at 18:06:41 UTC, jmh530 wrote:
> I think those are only for overwriting @nogc module, but the DIP should be more clear on this matter. I would assume you can import core.attribute to simplify that.

core.attribute will be implicitly imported. That is the FQN. As a regular attribute it can be aliased.

> Also, the DIP doesn't provide names for the attribute groups for the other ones. I assume GarbageCollectedness is just named that for the purpose of the example and is something that could be changed. Ideally, it would provide the names for each of the different groups as part of the DIP.

Heh, I know how much fun bike shedding is on the D forums...

On Thursday, 27 July 2017 at 23:27:53 UTC, Nicholas Wilson wrote:
>
>> 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).

So then you might make that more clear, such as by re-titling it "Function Attributes" instead of "Attributes" and change language in certain locations, like in the abstract, to refer to function attributions specifically instead of all attributes.

On Friday, 28 July 2017 at 00:20:25 UTC, jmh530 wrote:
> On Thursday, 27 July 2017 at 23:27:53 UTC, Nicholas Wilson wrote:
>>
>>> 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).
>
> So then you might make that more clear, such as by re-titling it "Function Attributes" instead of "Attributes" and change language in certain locations, like in the abstract, to refer to function attributions specifically instead of all attributes.

Thats a good idea.

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
> DIP 1012 is titled "Attributes".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

Terminology:
I was confused by the term "attribute group". Although the term is defined in the DIP, it implies a combination of attributes rather than a mutually exclusive attribute category.  Still having trouble understanding the DIP in detail due to this.

Rationale:
The rationale is weak, but reading the "Description" appears that there's more to this DIP than what the rationale describes.  I suggest an enumerated list of problem/solution pairs that this DIP addresses.

Description:
> It is also possible for the end user to directly control core.attribute.defaultAttributeSet by editing DRuntime directly.

Does this mean we can create an @safe-by-default or @final-by-default runtime?  if so, cool!, but that should be spelled out in more detail in the rationale.

> @core.attribute.GarbageCollectedness.inferred
That is way too verbose.  Is that just an illustration or is that really what we would need to be typing out?

Breaking changes / deprecation process:
It would be nice to get some decision early from the leadership if they would be willing to deprecate the no-leading-@ on attributes that are used with such proliferation in D code, as otherwise there will be a lot of time reviewing and debating this for nothing.  Sounds like a risky gamble.

Mike

On Friday, 28 July 2017 at 00:32:33 UTC, Mike wrote:
> On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
>> DIP 1012 is titled "Attributes".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
>
> Terminology:
> I was confused by the term "attribute group". Although the term is defined in the DIP, it implies a combination of attributes rather than a mutually exclusive attribute category.  Still having trouble understanding the DIP in detail due to this.

If you have a better name, please do tell.

>
> Rationale:
> The rationale is weak, but reading the "Description" appears that there's more to this DIP than what the rationale describes.  I suggest an enumerated list of problem/solution pairs that this DIP addresses.

Good idea.

> Description:
>> It is also possible for the end user to directly control core.attribute.defaultAttributeSet by editing DRuntime directly.
>
> Does this mean we can create an @safe-by-default or @final-by-default runtime?  if so, cool!, but that should be spelled out in more detail in the rationale.

Hmm, the runtime may have to be a special case for attribute inference,
I suspect that it does a whole bunch of things that are unsafe and the GC itself being @nogc is a bit weird (though I suppose you just link it out anyway). Not to mention global state being impure.

>> @core.attribute.GarbageCollectedness.inferred
> That is way too verbose.  Is that just an illustration or is that really what we would need to be typing out?
>

Illustration, I expect that one will be able to go

@infer!(GarbageCollectedness, FunctionSafety)
or
@infer!(nogc,safe)

to both mean the same thing (or a combination of the above), but infer will be the default anyway I suspect. where `infer` just selects the inferred value of the enum and build an AliasSeq from them

> Breaking changes / deprecation process:
> It would be nice to get some decision early from the leadership if they would be willing to deprecate the no-leading-@ on attributes that are used with such proliferation in D code, as otherwise there will be a lot of time reviewing and debating this for nothing.  Sounds like a risky gamble.
>
> Mike

IIRC the reason they lack a leading @ is purely historical and considered not good but not worth breaking code over. I believe this DIP presents an opportunity and reason to make that change. Existing code will still work i.e. we can deprecate the old form, since both the new and the old are implementation controlled, and make it become a positional keyword or the like.

On Friday, 28 July 2017 at 01:13:10 UTC, Nicholas Wilson wrote:

>> Terminology:
>> I was confused by the term "attribute group". Although the term is defined in the DIP, it implies a combination of attributes rather than a mutually exclusive attribute category.  Still having trouble understanding the DIP in detail due to this.
>
> If you have a better name, please do tell.

Yeah, naming is hard.  I suggest "attribute class".