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

Like others in this thread have said, it needs more rationale.  The rationale only mentions one actual problem: attributes can't be undone (which is a really important problem, by the way).  But in the abstract it says

> [This DIP] does not (yet) propose any mechanism to disable compiler attributes directly (e.g. @!nogc).

Instead of coming up with more problems to solve, it then dives into describing an entire framework for doing *things* with attributes.  To be totally honest, as it stands it feels like architecture astronautics:
https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

On Friday, 28 July 2017 at 01:26:19 UTC, Mike wrote:
> 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".

I like it.

On Friday, 28 July 2017 at 01:26:19 UTC, Mike wrote:
> 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".

Or "attribute category", maybe if the word "class" causes too much ambiguity.

On Friday, July 28, 2017 01:13:10 Nicholas Wilson via Digitalmars-d wrote:
> 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.

The only reason that _any_ of them have @ on them was to avoid creating a new keyword. And I for one would hate to see @ on all of them. It's just trading on inconsistency for another. Should public have @ on it? Should static have @ on it? What about scope, const, or shared? You're just taking a subset of the attributes and turning them into enums with @ on them and leaving some of them as-is. How is that making things more consistent? It's just shuffling the attributes around and for some reason turns some of them into enums while leaving others as they are.

IMHO, doing anything to change the current attributes had better have an _extremely_ good reason, and this DIP does not give that. Yes, being able to negate attributes would be valuable, but that really doesn't seem to be what this DIP is about much as that's what it gives as a rationale. Instead, it seems to be talking about altering attributes in a manner which makes them way more complicated than they are now.

I also _really_ don't like the idea of having aliases for built-in attributes. If we had that, instead of looking at a function and seeing @safe, pure, nothrow, etc., we could end up seing something like @VibeDefault, and then you'd have to go figure out what on earth that was, and even after you figured out what it was, it could change later. At least with what we have now, I can know what I'm looking at.

In addition, 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 (which we can already do with attributes like public or @safe but can't do with some of the others like pure or nothrow). It's a different thing entirely to basically change the default attributes via a compiler switch. That's just dividing the language. You end up with code that works with one set of compiler switches but not another and is thus incompatible with other code - because of a compiler switch. Walter has been against such compiler flags every time that they've come up, and I am in complete agreement. We've only used them as transitional flags that are supposed to go away eventually (like -dip25 or -dip1000). Whether the code is legal or not should not depend on the compiler flags.

And honestly, showing stuff like @core.attribute.GarbageCollectedness.gc in the DIP makes it look _really_ bad. Sure, it might make sense from the standpoint of extensibility, but it's ridiculously long. We already arguably have too much of an attribute mess on your average non-templated function signature without stuff like that.

IMHO, if what we're trying to do is to be able to negate attributes, then we should looking at doing something like @nogc(false) or some other syntax that is about negation of an existing attribute. This DIP is going off on a huge tangent from that with no justification as to why it would be worth the extra complication or the breakage that it would cause. And it looks like a _lot_ of extra complication in comparison to what we have now.

- Jonathan M Davis

On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
> On Friday, July 28, 2017 01:13:10 Nicholas Wilson via Digitalmars-d wrote:
>> 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.
>
> The only reason that _any_ of them have @ on them was to avoid creating a new keyword. And I for one would hate to see @ on all of them.

Fair enough, but its always slightly annoyed me that `pure` and `nothrow` don't have leading '@'s.

> It's just trading on inconsistency for another. Should public have @ on it? Should static have @ on it? What about scope, const, or shared? You're just taking a subset of the attributes and turning them into enums with @ on them and leaving some of them as-is.

This DIP is in the process of being amended to explicitly exclude linkage, storage class & visibility attributes. That Subset are function attributes under the 'Encompassed' and 'Optionally encompassed' subsections of "Attributes & attribute-like compiler behaviour encompassed in this DIP".

>How is that making things more
> consistent? It's just shuffling the attributes around and for some reason turns some of them into enums while leaving others as they are.

Its turning keyword-like compiler magic attributes into regular compiler attributes.

> IMHO, doing anything to change the current attributes had better have an _extremely_ good reason, and this DIP does not give that. Yes, being able to negate attributes would be valuable, but that really doesn't seem to be what this DIP is about much as that's what it gives as a rationale. Instead, it seems to be talking about altering attributes in a manner which makes them way more complicated than they are now.
>
> I also _really_ don't like the idea of having aliases for built-in attributes.

That is a feature.

> If we had that, instead of looking at a function and seeing @safe, pure, nothrow, etc., we could end up seing something like @VibeDefault, and then you'd have to go figure out what on earth that was, and even after you figured out what it was, it could change later. At least with what we have now, I can know what I'm looking at.

I dont mean to be snide but either
1) ignore them, i see AliasSeq of attributes more useful for end users, i.e. application developers, or
2) use an IDE.

>
> In addition, 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 (which we can already do with attributes like public or @safe but can't do with some of the others like pure or nothrow). It's a different thing entirely to basically change the default attributes via a compiler switch. That's just dividing the language. You end up with code that works with one set of compiler switches but not another and is thus incompatible with other code - because of a compiler switch. Walter has been against such compiler flags every time that they've come up, and I am in complete agreement. We've only used them as transitional flags that are supposed to go away eventually (like -dip25 or -dip1000). Whether the code is legal or not should not depend on the compiler flags.
>
> And honestly, showing stuff like @core.attribute.GarbageCollectedness.gc in the DIP makes it look _really_ bad.

That was an Illustrative mistake and I regret the confusion it has caused. I should have used `@gc` with `@gc` being an alias for @core.attribute.GarbageCollectedness.gc.

> Sure, it might make sense from the standpoint of extensibility, but it's ridiculously long. We already arguably have too much of an attribute mess on your average non-templated function signature without stuff like that.

This dip is intended to reduce the amount of attribute spam by enabling defaults.

> IMHO, if what we're trying to do is to be able to negate attributes, then we should looking at doing something like @nogc(false) or some other syntax that is about negation of an existing attribute.

The DIP is more than that, the benefit of being regular attributes (manipulation) and the ability to have configurable defaults,

> This DIP is going off on a huge tangent from that with no justification as to why it would be worth the extra complication or the breakage that it would cause.

This would cause _very_ little if any, non-deprecatable breakage.

> And it looks like a _lot_ of extra complication in comparison to what we have now.

The keyword-like attributes become regular attributes. I fail to see how that makes them any more complicated, IMO it makes them _less_ complicated (I am revising the DIP to remove the module related stuff and have a last applied wins for multiple attributes).

Am Thu, 27 Jul 2017 23:38:33 +0000
schrieb Nicholas Wilson <iamthewilsonator@hotmail.com>:

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

I think it also makes sense from a compiler perspective. When these attributes were introduce, we didn't have UDAs yet. Then we introduced UDAs and now UDAs are more full-featured than the original compiler hardcoded attributes:

UDAs do not introduce names into the global namespace, UDAs can use fully qualified names, multiple UDAs can be combined or aliased (as commonly done in C for dll export attributes using #defines. We can't do such things in D right now). So I think moving the compiler attributes to UDAs is certainly useful.

But it seems this DIP fails to stress the rationale and confuses people with some implementation detail. I think it's important to show the simple use cases, where object.d auto imports everything and aliases are used so you can use normal @nogc void foo()... syntax. Then maybe show how to group or alias attributes.

-- Johannes

On Friday, 28 July 2017 at 06:31:08 UTC, Johannes Pfau wrote:
> Am Thu, 27 Jul 2017 23:38:33 +0000
> schrieb Nicholas Wilson <iamthewilsonator@hotmail.com>:
>> 
>> 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.
>> 
>
> I think it also makes sense from a compiler perspective. When these attributes were introduce, we didn't have UDAs yet. Then we introduced UDAs and now UDAs are more full-featured than the original compiler hardcoded attributes:

Indeed all the LDC compiler specific attribute are regular UDAs. This also open the way for more parametric attributes and reduces the "urgh more attributes" and since they would be symbols we can phase the _in_ with `@future`.

> UDAs do not introduce names into the global namespace, UDAs can use fully qualified names, multiple UDAs can be combined or aliased (as commonly done in C for dll export attributes using #defines. We can't do such things in D right now). So I think moving the compiler attributes to UDAs is certainly useful.
>
> But it seems this DIP fails to stress the rationale and confuses people with some implementation detail. I think it's important to show the simple use cases, where object.d auto imports everything and aliases are used so you can use normal @nogc void foo()... syntax. Then maybe show how to group or alias attributes.
>
> -- Johannes

Duly noted.

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 was hoping an attribute overhaul would go in a different direction.
1) Remove all negation
2) Add an true/false yes/no parameter etc.

@gc!no:
  ...
@gc!yes:
  ...

On Friday, 28 July 2017 at 07:50:43 UTC, Daniel N 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
>>
>> 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 was hoping an attribute overhaul would go in a different direction.
> 1) Remove all negation
> 2) Add an true/false yes/no parameter etc.
>
> @gc!no:
>   ...
> @gc!yes:
>   ...

Or:


//Create symbol to attribute (new kind of symbol)
__attribute Pure = pure;

alias PureIf(bool X : true) = Pure;
alias PureIf(bool X : false) = AliasSeq!();


//expand UDA PureIf to pure if IsPure == true
void test(bool IsPure)()@PureIf!IsPure{
}

//can be in std.attrib or similar module:
__attribute Safe = @safe;
__attribute Nothrow = nothrow;

alias As = AliasSeq!(Pure, Nothrow, Safe);

//expand to pure nothrow @safe
void test2()@As{		

}

On Friday, 28 July 2017 at 01:30:28 UTC, sarn wrote:
> To be totally honest, as it stands it feels like architecture astronautics:
> https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

Yeah, I think you nailed it. This DIP does seem to come from a 'what is the smartest, most elegant system I can design' logic; I don't see much value in it as something that would solve problems.

That's not to say that the rationale should be explained better, or the examples should be different, or this or that paragraph should be tweaked. I think this proposal is fundamentally flawed for the reasons Jonathan M Davis outlined.