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!

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
>
> 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!

"at the top of a file means that one can never "undo" those attributes"

That's not true for `@safe`. This is perfectly legal:

@safe:

void foo()  { ... }    // foo is @safe
void bar() @system { } // bar is @system


_Why_ it works like that I have no idea.

Atila

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

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.

The DIP's written rationale is fairly short, and only mentions "We need a way to conveniently change default values for attributes" which I feel doesn't really justifies these complex new semantics.

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.

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
>
> 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!

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.

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.

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.

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.

On Thu, 27 Jul 2017 14:44:23 +0000, Mike Parker wrote:

> DIP 1012 is titled "Attributes".
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md


1. I would like to see consistency; I'd rather see @nogc and @gc than @nogc and @core.attributes.[whatever].gc, so all these attributes should be aliased alike.

2. I don't really understand the need for this. The two times I wanted a whole module @safe but failed (so note I'm speaking from a lack of experience), I just placed the one or two functions above the attribute.

Though mixing combinations of attributes on functions would be greatly simplified by this proposal, I personally don't know how common that is, so I don't know the value in the proposal.

3. I don't like @inferred. If I'm going to call a function, I need to know whether I can call it from a @safe/@nogc/@whatever function. I can't imagine trying to work with Phobos (or any other library) if it documented @inferred everywhere. Unless I've missed the point.

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
> Destroy!

Extend rationale: could be application to templates and using with CTFE.

"inferred" is not consistent. As I understand inferred applies to templates only. And default value is so called inferred_or_system. So it is inferred for templates and system for everything else. So whole safety group is:
 - safe
 - system
 - trusted
 - inferred_or_safe / soft_safe
 - inferred_or_system / soft_system

On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote:
> "at the top of a file means that one can never "undo" those attributes"
>
> That's not true for `@safe`. This is perfectly legal:
>
> @safe:
>
> void foo()  { ... }    // foo is @safe
> void bar() @system { } // bar is @system
>
>
> _Why_ it works like that I have no idea.
>
> Atila

Huh.  I guess it's because there are three values in that group, unlike the rest of them, and the compiler handles them differently.