www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1012--Attributes--Preliminary Review Round 1

reply Mike Parker <aldacron gmail.com> writes:
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!
Jul 27
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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
Jul 27
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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
Jul 27
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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).
Jul 27
parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Jul 27
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
prev sibling next sibling parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
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.
Jul 27
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
parent reply Johannes Pfau <nospam example.com> writes:
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
Jul 27
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
Jul 27
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
prev sibling next sibling parent reply Adrian Matoga <dlang.spam matoga.info> writes:
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.
Jul 27
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Jul 27
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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...
Jul 27
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
prev sibling next sibling parent rjframe <dlang ryanjframe.com> writes:
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.
Jul 27
prev sibling next sibling parent Iakh <iaktakh gmail.com> writes:
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
Jul 27
prev sibling next sibling parent reply Mike <none none.com> writes:
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
Jul 27
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
next sibling parent reply Mike <none none.com> writes:
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".
Jul 27
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 27
prev sibling parent Mike <none none.com> writes:
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.
Jul 27
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jul 27
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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).
Jul 27
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
 Should public have   on it? Should static have   on it? What 
 about scope, const, or shared?
If they are storage classes, they shouldn't have . If they are statement or expression keywords, they shouldn't have . Things like that are introduced with leading underscores: __traits, __gshared. public etc could be attributes, but I see no reason to change them. This inconsistency can be explained by just saying visibility is special. (That said I wouldn't complain if they were changed too). Common keywords in other languages can help justify keeping those keywords in D.
 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
This is one part of the DIP I like - ` safe module foo;`. AIUI this would enable a safe default that doesn't stop code such as templates being inferred as system. This is not currently possible in D. I know Walter has talked about inferring attributes for all function bodies - in that case the DIP seems a bit less useful, but could still set the default for unittests, module ctors/dtors and main().
Jul 28
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 28 July 2017 at 11:45:21 UTC, Nick Treleaven wrote:
 On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
 Should public have   on it? Should static have   on it? What 
 about scope, const, or shared?
If they are storage classes, they shouldn't have . If they are statement or expression keywords, they shouldn't have . Things like that are introduced with leading underscores: __traits, __gshared. public etc could be attributes, but I see no reason to change them. This inconsistency can be explained by just saying visibility is special. (That said I wouldn't complain if they were changed too). Common keywords in other languages can help justify keeping those keywords in D.
the only catch there is that the `package` visibility takes an optional module following it and therefore can't be done as an enum.
 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
This is one part of the DIP I like - ` safe module foo;`. AIUI this would enable a safe default that doesn't stop code such as templates being inferred as system. This is not currently possible in D. I know Walter has talked about inferring attributes for all function bodies - in that case the DIP seems a bit less useful, but could still set the default for unittests, module ctors/dtors and main().
Hmm, after some discussions in this thread I decided that it would be better to have a "last applied wins" rule so as not to need the whole tag the module decl to set the default for the module. I suppose it could be bought back if need be but it's kind of redundant with "last applied wins". Templates may still be a bit of a problem.
Jul 28
prev sibling next sibling parent reply sarn <sarn theartofmachinery.com> writes:
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/
Jul 27
parent Olivier FAURE <olivier.faure epitech.eu> writes:
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.
Jul 28
prev sibling next sibling parent reply Daniel N <no public.email> writes:
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: ...
Jul 28
parent vit <vit vit.vit> writes:
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{ }
Jul 28
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
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
 Thanks in advance to all who participate.

 Destroy!
My primary points * Don't formally deprecate the keywords, there is not enough justification to ever remove them. * Remove the whole program defaults, I'm ok with it being changed in a re-implementation of the runtime (like the embedded example), we just don't need the extra confusion within user code. * Specifying inferred needs to be within druntime only, and thus may not need to exist. * I'm concerned user defined attributes could define a "defaults" for functions. I think the updated document needs some additional rework, here are some examples: # Rational A number of issues with the existing functional attribute system have come up through the years. * Certain attributes don't have a name, e.g. All functions ''throws'' but this is not an existing attribute. * The default attributes were not correctly chosen, e.g. all class methods should be ''final'' unless specified otherwise, and because of the first point declaring 'final:' at the top of the class cannot be undone. * AliasSeq is provided to manage Attributes, but it doesn't handle built in attributes (I could be wrong but is what I'm getting from the document even though it isn't explicitly stated) * ... # Description Function existing attributes and their unnamed counterpart will exist as an enum within core.attributes. This module will be implicitly imported to provide the symbols without explicit import or breaking existing code. The compiler will recognize the non- based attributes as the corresponding core.attribute. ... ## Implementation Details ---------- module core.attribute; enum Protection { system, safe, trusted, } alias safe = Protection.safe; ... ----------- The compiler will default functions to the first value of the enum [for my example]. [So on and so forth]
Jul 28
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips 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
 Thanks in advance to all who participate.

 Destroy!
My primary points * Don't formally deprecate the keywords, there is not enough justification to ever remove them.
Indeed the only reason for removing them would be to remove code from the compiler. They do no harm at all.
 * Remove the whole program defaults, I'm ok with it being 
 changed in a re-implementation of the runtime (like the 
 embedded example), we just don't need the extra confusion 
 within user code.
The program defaults are there to make safe by default a thing, and betterC by default a thing, which are covered in the _three Primary points_ of the semesters Vision document[1]. These would not normally be set (i.e. opt in).
 * Specifying inferred needs to be within druntime only, and 
 thus may not need to exist.
I think there is usefulness in having it, particularly as the meta-default (defaultAttributeSet). Walter has ben pushing for some time to infer attributes by default. This would provide a directive for the compiler to do so. Please elaborate.
 * I'm concerned user defined attributes could define a 
 "defaults" for functions.
you mean user UDAs (if not please explain)? the default application of UDA is for core attributes only.
 I think the updated document needs some additional rework, here 
 are some examples:

 # Rational

 A number of issues with the existing functional attribute 
 system have come up through the years.

 * Certain attributes don't have a name, e.g. All functions 
 ''throws'' but this is not an existing attribute.
 * The default attributes were not correctly chosen, e.g. all 
 class methods should be ''final'' unless specified otherwise, 
 and because of the first point declaring 'final:' at the top of 
 the class cannot be undone.
 * AliasSeq is provided to manage Attributes, but it doesn't 
 handle built in attributes (I could be wrong but is what I'm 
 getting from the document even though it isn't explicitly 
 stated)
 * ...

 # Description

 Function existing attributes and their unnamed counterpart will 
 exist as an enum within core.attributes. This module will be 
 implicitly imported to provide the symbols without explicit 
 import or breaking existing code. The compiler will recognize 
 the non-  based attributes as the corresponding core.attribute.

 ...

 ## Implementation Details

 ----------
 module core.attribute;

 enum Protection {
 system,
 safe,
 trusted,
 }

 alias safe = Protection.safe;
 ...
 -----------

 The compiler will default functions to the first value of the 
 enum [for my example].
( That would provide a pessimistic default and debates the ability for the compiler to infer)
 [So on and so forth]
Thanks for your suggestions. [1]: https://wiki.dlang.org/Vision/2017H2
Jul 28
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:
 On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
 * Remove the whole program defaults, I'm ok with it being 
 changed in a re-implementation of the runtime (like the 
 embedded example), we just don't need the extra confusion 
 within user code.
The program defaults are there to make safe by default a thing, and betterC by default a thing, which are covered in the _three Primary points_ of the semesters Vision document[1]. These would not normally be set (i.e. opt in).
I read that as more, Improve Druntime and phobos's us of safe so that it becomes more usable.
 * Specifying inferred needs to be within druntime only, and 
 thus may not need to exist.
I think there is usefulness in having it, particularly as the meta-default (defaultAttributeSet). Walter has ben pushing for some time to infer attributes by default. This would provide a directive for the compiler to do so. Please elaborate.
I don't expect inference to happen outside templates. Besides if the compiler infers the appropriate attributes by default, isn't 1. a default attribute redundant and 2. specifying inference redundant as the compiler defaults to inferring?
 * I'm concerned user defined attributes could define a 
 "defaults" for functions.
you mean user UDAs (if not please explain)? the default application of UDA is for core attributes only.
Yes I'm User's UDA (user defined attributes). I expected it wouldn't apply outside the context of core.attributes.
 The compiler will default functions to the first value of the 
 enum [for my example].
( That would provide a pessimistic default and debates the ability for the compiler to infer)
Yes, just throwing in an example structure and why I mentioned [for my example]. But as said earlier infer and default are at odds.
 [So on and so forth]
Thanks for your suggestions. [1]: https://wiki.dlang.org/Vision/2017H2
Jul 31
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 31 July 2017 at 19:27:46 UTC, Jesse Phillips wrote:
 On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:
 On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
 * Remove the whole program defaults, I'm ok with it being 
 changed in a re-implementation of the runtime (like the 
 embedded example), we just don't need the extra confusion 
 within user code.
The program defaults are there to make safe by default a thing, and betterC by default a thing, which are covered in the _three Primary points_ of the semesters Vision document[1]. These would not normally be set (i.e. opt in).
I read that as more, Improve Druntime and phobos's us of safe so that it becomes more usable.
Improving druntime and phobos is obviously important, but so is the ability for the end user to use it. If its hard to use less people will use it, conversely the easier it is the more likely people are to use it. Not that this also provides an easy way to find out which function are not safe and fix them, without slapping safe on main, i.e. build unit (package/library) at a time.
 * Specifying inferred needs to be within druntime only, and 
 thus may not need to exist.
I think there is usefulness in having it, particularly as the meta-default (defaultAttributeSet). Walter has ben pushing for some time to infer attributes by default. This would provide a directive for the compiler to do so. Please elaborate.
I don't expect inference to happen outside templates. Besides if the compiler infers the appropriate attributes by default, isn't 1. a default attribute redundant and 2. specifying inference redundant as the compiler defaults to inferring?
It happens already for dip1000 IIRC and I be surprised if, particularly for safe, Walter didn't want more inference. Especially for minimal user effort.
 The compiler will default functions to the first value of the 
 enum [for my example].
( That would provide a pessimistic default and debates the ability for the compiler to infer)
Yes, just throwing in an example structure and why I mentioned [for my example]. But as said earlier infer and default are at odds.
I disagree. Even if infer wasn't the default I would certainly like to be able to have them be inferred at the flick of a compiler switch. It goes back to the ease of use argument, its more effort for me to manually annotate things.
Jul 31