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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
prev sibling next 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:



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



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.

...



----------
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 2017
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:



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



 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.

 ...



 ----------
 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 2017
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 2017
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 2017
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.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.


I don't know what's happening with this DIP, but I've recently 
encountered a real-world problem for which there is no palatable 
workaround that this DIP would likely solve:

https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123

My attempts to workaround the issue I posted at
https://forum.dlang.org/post/uhgzgmowqcczczrdtsol forum.dlang.org

That PR may be useful for motivating this DIP.

Mike
May 27 2018
parent sarn <sarn theartofmachinery.com> writes:
On Sunday, 27 May 2018 at 13:44:40 UTC, Mike Franklin wrote:

 I don't know what's happening with this DIP, but I've recently 
 encountered a real-world problem for which there is no 
 palatable workaround that this DIP would likely solve:

 https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123

 My attempts to workaround the issue I posted at
 https://forum.dlang.org/post/uhgzgmowqcczczrdtsol forum.dlang.org

 That PR may be useful for motivating this DIP.

 Mike


It looks like all you need is a way to toggle attributes with a 
flag, like pure(isPure) or something.  IIRC, last time that came 
up, it turned into a bikeshedding fest about the syntax.  (I 
don't think parentheses works with UDAs.)  Anyway, yeah, we need 
the functionality.

However, this DIP is *way* more complicated.  I stand by what I 
said before: 
https://forum.dlang.org/post/dnmcqwkdfmommiiugcvv forum.dlang.org 
  Jonathan M Davis said it in long form: 
https://forum.dlang.org/post/mailman.5429.1501206646.31550.digitalmars-d puremagic.com
May 27 2018
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
The proposal says that builtin attributes are replaced by UDAs 
defined in the runtime. But user-defined attributes don't work 
like  safe,  system, and  trusted:

---
struct Attr {}
 Attr  safe:
class Foo
{
   // this function is  safe but not  Attr
   void doStuff() {}
}
---

In order to make the proposal work as intended, in a 
backwards-compatible way, the attributes in core.attributes need 
to be able to specify whether they descend into nested 
declarations or not.

It would be handy for arbitrary user-defined attributes to be 
able to specify this, too.
Dec 20 2018