www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP64: Attribute Cleanup

reply "Brian Schott" <briancschott gmail.com> writes:
http://wiki.dlang.org/DIP64

Attributes in D have two problems:
1. There are too many of them and declarations are getting too 
verbose
2. New attributes use   and the old ones do not.

I've created a DIP to address these issues.
Jun 20 2014
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
I like it. Just thinking aloud, it could be interesting to allow compile time logic of some sort (both on the arguments and on the symbol the attribute is being attached to). Contrived example borrowing template syntax (which could almost certainly be improved upon): template pureIfNameHasPure(Sym) { static if(__traits(identifier, Sym).canFind("Pure)) alias pureIfNameHasPure = pure; else alias pureIfNameHasPure = /* nothing...not sure how to show that */; }
Jun 20 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jun 20, 2014 at 07:22:02PM +0000, Brian Schott via Digitalmars-d wrote:
 http://wiki.dlang.org/DIP64
 
 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too verbose
 2. New attributes use   and the old ones do not.
 
 I've created a DIP to address these issues.
And while we're at it, why not also fix holes in attribute semantics on top of just fixing syntax? First, there is no way to mark a function as *impure* as opposed to pure (leaving out "pure" is not an option in template functions due to automatic attribute inference). Also, there's an inconsistency between positive attributes (pure, safe) vs. negative attributes (nothrow, nogc). So ideally, the new syntax should allow you to specify both pure and impure, and ideally, it should not special-case on peculiarities of the English language (pure/impure vs. throw/nothrow). So it should be something like pure, !pure, throw, !throw, gc, !gc, etc., for maximum consistency. I also like your attribute sets idea. This could be the solution we're looking for with transitive attributes (aka inout(pure), inout(nothrow), etc.). If there was some syntax for attribute set intersection, say a* b, then we could specify that the attribute set of some given function f() is the intersection of the attribute sets of its input delegates. For example: // This is hypothetical syntax, I'm sure you can think of a // better way to write this. int dgCaller(int delegate(int) a dg1, int delegate(int) b dg2) this = a* b // specifies that this function's // attributes is the intersection of a and b { if (someCondition) return dg1(1); else return dg2(2); } T -- Heads I win, tails you lose.
Jun 20 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Friday, 20 June 2014 at 19:48:49 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 First, there is no way to mark a function as *impure* as 
 opposed to pure
 (leaving out "pure" is not an option in template functions due 
 to
 automatic attribute inference). Also, there's an inconsistency 
 between
 positive attributes (pure, safe) vs. negative attributes 
 (nothrow,
 nogc). So ideally, the new syntax should allow you to specify 
 both pure
 and impure, and ideally, it should not special-case on 
 peculiarities of
 the English language (pure/impure vs. throw/nothrow). So it 
 should be
 something like  pure,  !pure,  throw,  !throw,  gc,  !gc, etc., 
 for
 maximum consistency.
I can see this being useful. We'd just have to decide what it means to negate an attribute with arguments. (e.g. ` !name("bob")`) Also in the case of !throw we'd have to modify the definition of attributes to accept the "throw" token instead of just identifiers. Maybe converting "nothrow" to " !throws" would be better.
 I also like your attribute sets idea. This could be the 
 solution we're
 looking for with transitive attributes (aka inout(pure), 
 inout(nothrow),
 etc.). If there was some syntax for attribute set intersection, 
 say
  a* b, then we could specify that the attribute set of some 
 given
 function f() is the intersection of the attribute sets of its 
 input
 delegates. For example:

 	// This is hypothetical syntax, I'm sure you can think of a
 	// better way to write this.
 	int dgCaller(int delegate(int)  a dg1, int delegate(int)  b 
 dg2)
 		 this =  a* b // specifies that this function's
 			      // attributes is the intersection of  a and  b
 	{
 		if (someCondition)
 			return dg1(1);
 		else
 			return dg2(2);
 	}


 T
Is that use case common enough to justify complicating the compiler?
Jun 20 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 20 Jun 2014 15:47:07 -0400, H. S. Teoh via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 On Fri, Jun 20, 2014 at 07:22:02PM +0000, Brian Schott via Digitalmars-d  
 wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
And while we're at it, why not also fix holes in attribute semantics on top of just fixing syntax? First, there is no way to mark a function as *impure* as opposed to pure (leaving out "pure" is not an option in template functions due to automatic attribute inference). Also, there's an inconsistency between positive attributes (pure, safe) vs. negative attributes (nothrow, nogc). So ideally, the new syntax should allow you to specify both pure and impure, and ideally, it should not special-case on peculiarities of the English language (pure/impure vs. throw/nothrow). So it should be something like pure, !pure, throw, !throw, gc, !gc, etc., for maximum consistency.
I like the idea, but seeing as how attribute sets already take arguments, it's natural to add them to builtins: pure(true) == pure pure(false) == not pure -Steve
Jun 20 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Does this work for all attributes? For example: OneTo5 = (1) (2) (3) (4) (5); And will this be possible? struct Test { string str; } Tattr(str) = Test(str); Tattr = Test("");
Jun 20 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
They do need standardising but i don't like the idea of attribute sets. Attribute sets would make attributes too over complicated to understand. Attributes need to be simple and concise which i think they already are.
Jun 20 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
It may be worth splitting things up a little, or perhaps the extra parts in the DIP are your 'duck.' Because I think normalising every attribute to syntax is good. I look at it and think, "Yeah, good." Especially so if it also means that user defined attributes can also be on both sides of a function signature, as that would ease transition between different versions of the language. I think the parts in the DIP about the exact semantics or syntax for composing attributes will be debated a bit, but the "Let's just put in there" part is pretty straightforward.
Jun 20 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 20 Jun 2014 15:22:02 -0400, Brian Schott <briancschott gmail.com>  
wrote:

 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
I like it. At first, I thought "hm.., every project is going to have their own definition for safe pure nothrow," but we can put one in druntime common sets that everyone should use, and we already allow custom attributes anyway that have to be looked up. One thing this will make slightly more difficult is looking for e.g. trusted functions, because you can't just grep for them. However, I think with DScanner, you can probably find things easy enough. 2 thoughts: 1. On H.S.Teoh's idea to add negation, what does foo() pure ! pure mean (or if my preferred syntax was accepted, pure pure(false) )? 2. What does this print? myattr = safe pure; void foo() myattr {} pragma(msg, (&foo).typeof); -Steve
Jun 20 2014
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/20/2014 09:22 PM, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Why not make the built-in attributes proper symbols instead and use alias Seq(T...)=T; alias spiffy = Seq!(pure,nothrow,safe); float mul(float a, float b) spiffy{ } ? This will also allow use cases such as passing attributes by alias.
Jun 20 2014
next sibling parent "Philpax" <phillip philliplarkson.com> writes:
+1 to this proposal; as someone trying to annotate their D code 
appropriately, the inconsistency in the usage of   forces me to 
look up the docs every time, which leads to considerable 
productivity loss. I'm sure it's less of an issue when one is 
sufficiently versed in annotation, but I find it quite annoying 
right now.
Jun 20 2014
prev sibling parent reply "Mason McGill" <mmcgill caltech.edu> writes:
On Friday, 20 June 2014 at 22:01:31 UTC, Timon Gehr wrote:
 On 06/20/2014 09:22 PM, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Why not make the built-in attributes proper symbols instead and use alias Seq(T...)=T; alias spiffy = Seq!(pure,nothrow,safe); float mul(float a, float b) spiffy{ } ? This will also allow use cases such as passing attributes by alias.
I think this would make the language a lot cleaner, and can be taken even further: extern("C++", "some.namespace") class C { private int x; } Here `extern` is a regular function that returns an instance of some compiler-defined type. This makes "built-in" attributes just particular cases of properties (that happen to be recognized by the compiler). "Attribute" and "property" are pretty much synonyms in English, and it always seemed strange to me that D had to define them as different--yet confusingly similar--entities.
Jun 21 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 22 Jun 2014 00:12:20 +0000
Mason McGill via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "Attribute" and "property" are pretty much synonyms in English,
 and it always seemed strange to me that D had to define them as
 different--yet confusingly similar--entities.
They're not even vaguely similar in D. A property is a member of a struct or class which is a variable or a function which emulates a variable, whereas attributes are annotations put on symbols (currently just classes, structs, and functions AFAIK) which indicate extra information to the compiler and to type introspection. So, while I can see why you might dislike the fact that attribute and property do not mean the same thing in D, they're _not_ at all similar it how they're used, so I find it very odd if anyone is confusing them. And it's not like D pioneered these meanings for attributes and properties. C# uses them for the same things. - Jonatahn M Davis
Jun 21 2014
parent reply "Mason McGill" <mmcgill caltech.edu> writes:
On Sunday, 22 June 2014 at 05:18:05 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 On Sun, 22 Jun 2014 00:12:20 +0000
 Mason McGill via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 "Attribute" and "property" are pretty much synonyms in English,
 and it always seemed strange to me that D had to define them as
 different--yet confusingly similar--entities.
They're not even vaguely similar in D. A property is a member of a struct or class which is a variable or a function which emulates a variable, whereas attributes are annotations put on symbols (currently just classes, structs, and functions AFAIK) which indicate extra information to the compiler and to type introspection. So, while I can see why you might dislike the fact that attribute and property do not mean the same thing in D, they're _not_ at all similar it how they're used, so I find it very odd if anyone is confusing them. And it's not like D pioneered these meanings for attributes and properties. C# uses them for the same things. - Jonatahn M Davis
I was referring to the `Property` and `PropertyIdentifier` entities in the D grammar (http://dlang.org/attribute.html), which are special cases of attributes. "New-style" attributes, like "property", "safe", and "nogc", are `PropertyIdentifier`s and need to be written with the " " character. Older, non-property attributes, like "pure" and "nothrow", do not. Sorry if this wasn't clear in the former post.
Jun 21 2014
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 22 Jun 2014 05:49:33 +0000
Mason McGill via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I was referring to the `Property` and `PropertyIdentifier`
 entities in the D grammar (http://dlang.org/attribute.html),
 which are special cases of attributes. "New-style" attributes,
 like "property", "safe", and "nogc", are `PropertyIdentifier`s
 and need to be written with the " " character. Older,
 non-property attributes, like "pure" and "nothrow", do not.

 Sorry if this wasn't clear in the former post.
That _is_ kind of an ugly use of the word property. - Jonathan M Davis
Jun 21 2014
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
I agree that the lack of consistency with is annoying, and was especially annoying when I was starting to learn D. Having to look up every time whether you need an is the type of inconsistent baggage that D should not have. I do like the idea of attribute sets, but I'm not sure if others will as it could be somewhat confusing. For example, if final(false) gets in, the first thing I would be doing is making an attribute set virtual that just expands to final(false) (incidentally, this would make me much less opposed to the final(false) syntax).
Jun 21 2014
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64
All things being equal, it would be nicer to have consistency, but do we really I want to break almost all existing code? I know you've proposed a tool to do the transition, but there are lots of unmaintained projects out there that are still used, and tutorials/articles/books/university courses written using the existing syntax. Those likely won't be, or can't be changed easily. One possible compromise might be to leave the old syntax there for legacy reasons, but allow (and encourage) pure, nothrow, etc.
Jun 21 2014
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Saturday, 21 June 2014 at 17:11:24 UTC, Peter Alexander wrote:
 On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64
All things being equal, it would be nicer to have consistency, but do we really I want to break almost all existing code? I know you've proposed a tool to do the transition, but there are lots of unmaintained projects out there that are still used, and tutorials/articles/books/university courses written using the existing syntax. Those likely won't be, or can't be changed easily. One possible compromise might be to leave the old syntax there for legacy reasons, but allow (and encourage) pure, nothrow, etc.
I completely agree with your point, but if things never get cleaned up we'll need a guy like Scott Meyers to explain the overcomplicated result. I don't know how to resolve this issue, opponents of change will claim that a language will never get traction if it changes too much too quickly, and proponents will claim that not removing inconsistencies leads to a mess. Both are right.
Jun 21 2014
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 21 June 2014 at 17:20:08 UTC, Brian Rogoff wrote:
 I completely agree with your point, but if things never get 
 cleaned up we'll need a guy like Scott Meyers to explain the 
 overcomplicated result. I don't know how to resolve this issue, 
 opponents of change will claim that a language will never get 
 traction if it changes too much too quickly, and proponents 
 will claim that not removing inconsistencies leads to a mess. 
 Both are right.
Like most things in engineering, there is no right answer, and there are compromises all the way. You just have to weigh up the pros and cons and make a decision. Of course, reasonable people may disagree on the weights, so some debate may be necessary. The pros and cons are clear here. I think it would be nice to have consistent syntax and keep Scott away, but it's just syntax. It doesn't affect the expressiveness, power, or performance of the language. The cost is that it breaks almost all working code. I do not think the pros outweigh the cons, so I do not think this should go ahead, and we will just have to live with Scott explaining why some attributes have and others do not.
Jun 21 2014
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 21 Jun 2014 17:54:33 +0000
Peter Alexander via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Saturday, 21 June 2014 at 17:20:08 UTC, Brian Rogoff wrote:
 I completely agree with your point, but if things never get
 cleaned up we'll need a guy like Scott Meyers to explain the
 overcomplicated result. I don't know how to resolve this issue,
 opponents of change will claim that a language will never get
 traction if it changes too much too quickly, and proponents
 will claim that not removing inconsistencies leads to a mess.
 Both are right.
Like most things in engineering, there is no right answer, and there are compromises all the way. You just have to weigh up the pros and cons and make a decision. Of course, reasonable people may disagree on the weights, so some debate may be necessary. The pros and cons are clear here. I think it would be nice to have consistent syntax and keep Scott away, but it's just syntax. It doesn't affect the expressiveness, power, or performance of the language. The cost is that it breaks almost all working code. I do not think the pros outweigh the cons, so I do not think this should go ahead, and we will just have to live with Scott explaining why some attributes have and others do not.
And to add to that, this proposal doesn't even make things consistent. You _still_ have to explain why some attributes have and some don't. It's just that now two of them have whereas they didn't before. final, static, public, const, etc. all still don't have , and they're all function attributes too. So, it doesn't increase consistency. It just moves it around. And then we have to explain why some older code or tutorials _don't_ have on pure or nothrow, making it so that we have _more_ to explain. I appreciate the sentiment of wanting to clean things up and make them more consistent, but I really don't think this does that. If we want that, we'd either have to add to all attributes or remove it from all attributes. But then of course, we'd have stuff like public and static, which is inconsistent with other languages and would probably cause folks to complain about unnecessary inconsistencies with othe languages. So, I really don't think that we can avoid this problem. It's just a question of which form of it we want to deal with and how much code breakage we're willing to put up with to get it there. - Jonathan M Davis
Jun 21 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 21 June 2014 at 19:41:42 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 And to add to that, this proposal doesn't even make things 
 consistent. You
 _still_ have to explain why some attributes have   and some 
 don't. It's just
 that now two of them have   whereas they didn't before. final, 
 static, public,
 const, etc. all still don't have  , and they're all function 
 attributes too.
I think the proposal said that the type constructors would be exempt, You wouldn't have const but you would have final.
 So, it doesn't increase consistency. It just moves it around. 
 And then we have
 to explain why some older code or tutorials _don't_ have   on 
 pure or nothrow,
 making it so that we have _more_ to explain.
We can either say "It used to be inconsistent, but then we did nothing", or "It used to be inconsistent, but then we fixed it. Run this tool on your code and you'll be fine."
 I appreciate the sentiment of wanting to clean things up and 
 make them more
 consistent, but I really don't think this does that. If we want 
 that, we'd
 either have to add   to all attributes or remove it from all 
 attributes. But
 then of course, we'd have stuff like  public and  static, which 
 is
 inconsistent with other languages and would probably cause 
 folks to complain
 about unnecessary inconsistencies with othe languages. So, I 
 really don't
 think that we can avoid this problem. It's just a question of 
 which form of it
 we want to deal with and how much code breakage we're willing 
 to put up with
 to get it there.
Why is D being consistent with other languages a more important goal than D being consistent with D?
Jun 21 2014
next sibling parent "francesco cattoglio" <francesco.cattoglio gmail.com> writes:
On Saturday, 21 June 2014 at 20:48:41 UTC, Brian Schott wrote:
 I think the proposal said that the type constructors would be 
 exempt, You wouldn't have  const but you would have  final.
I think you needed to underline this part better. This is indeed extremely important, and that is the reason for people complaining about your DIP being only "just moving inconsistencies around"
Jun 21 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 21 Jun 2014 20:48:40 +0000
Brian Schott via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Saturday, 21 June 2014 at 19:41:42 UTC, Jonathan M Davis via
 Digitalmars-d wrote:
 And to add to that, this proposal doesn't even make things
 consistent. You
 _still_ have to explain why some attributes have   and some
 don't. It's just
 that now two of them have   whereas they didn't before. final,
 static, public,
 const, etc. all still don't have  , and they're all function
 attributes too.
I think the proposal said that the type constructors would be exempt, You wouldn't have const but you would have final.
I thought that it called out pure and nothrow explicitly. I'll have to reread it.
 So, it doesn't increase consistency. It just moves it around.
 And then we have
 to explain why some older code or tutorials _don't_ have   on
 pure or nothrow,
 making it so that we have _more_ to explain.
We can either say "It used to be inconsistent, but then we did nothing", or "It used to be inconsistent, but then we fixed it. Run this tool on your code and you'll be fine."
But as far is I can tell, this doesn't even make the language consistent. It just moves the inconsistencies around.
 I appreciate the sentiment of wanting to clean things up and
 make them more
 consistent, but I really don't think this does that. If we want
 that, we'd
 either have to add   to all attributes or remove it from all
 attributes. But
 then of course, we'd have stuff like  public and  static, which
 is
 inconsistent with other languages and would probably cause
 folks to complain
 about unnecessary inconsistencies with othe languages. So, I
 really don't
 think that we can avoid this problem. It's just a question of
 which form of it
 we want to deal with and how much code breakage we're willing
 to put up with
 to get it there.
Why is D being consistent with other languages a more important goal than D being consistent with D?
It's not, but there _is_ a cost to making it less consistent with other languages, especially when it's _currently_ consistent with them. And it's definitely not worth becoming inconsistent with other languages IMHO if you're not actually fixing the inconsistencies in D at the same time. We either need to make attributes _completely_ consistent, or there's no point in changing any of them. And that would mean either putting on the front of _all_ of them or _none_ of them, not simply adding to a few of them. - Jonathan M Davis
Jun 21 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 21 Jun 2014 22:07:22 -0700
Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Sat, 21 Jun 2014 20:48:40 +0000
 Brian Schott via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Why is D being consistent with other languages a more important
 goal than D being consistent with D?
It's not, but there _is_ a cost to making it less consistent with other languages, especially when it's _currently_ consistent with them. And it's definitely not worth becoming inconsistent with other languages IMHO if you're not actually fixing the inconsistencies in D at the same time. We either need to make attributes _completely_ consistent, or there's no point in changing any of them. And that would mean either putting on the front of _all_ of them or _none_ of them, not simply adding to a few of them.
And actually, the more that I think about this, the less that I like the idea. It's bad enough that we have safe, property, etc., but having to put on all of the attributes? I don't want to have public, static, final etc. It's just ugly and more verbose. I'd much rather just put up with having to explain to people that we didn't want to add new keywords and that that's why safe, trusted, system, property, and nogc have on them and nothing else does - i.e. it's pretty much purely a question of age. Sure, the inconsitency sucks, but I think that it would suck more to have to have everywhere. I wouldn't mind having safe and company changed to keywords to make the attributes consistent, but I very much doubt that that would be acceptable at this point. - Jonathan M Davis
Jun 21 2014
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Sunday, 22 June 2014 at 06:37:22 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 On Sat, 21 Jun 2014 22:07:22 -0700

 I'd much rather just put up with having to explain to people 
 that we didn't
 want to add new keywords and that that's why  safe,  trusted, 
  system,
  property, and  nogc have   on them and nothing else does - 
 i.e. it's pretty
 much purely a question of age. Sure, the inconsitency sucks, 
 but I think that
 it would suck more to have to have   everywhere. I wouldn't 
 mind having  safe
 and company changed to keywords to make the attributes 
 consistent, but I very
 much doubt that that would be acceptable at this point.

 - Jonathan M Davis
+1 --- Paolo
Jun 22 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Jun 21, 2014 at 12:41:26PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
 And to add to that, this proposal doesn't even make things consistent.
 You _still_ have to explain why some attributes have   and some don't.
 It's just that now two of them have   whereas they didn't before.
 final, static, public, const, etc. all still don't have  , and they're
 all function attributes too.  So, it doesn't increase consistency. It
 just moves it around. And then we have to explain why some older code
 or tutorials _don't_ have   on pure or nothrow, making it so that we
 have _more_ to explain.
 
 I appreciate the sentiment of wanting to clean things up and make them
 more consistent, but I really don't think this does that. If we want
 that, we'd either have to add   to all attributes or remove it from
 all attributes. But then of course, we'd have stuff like  public and
  static, which is inconsistent with other languages and would probably
 cause folks to complain about unnecessary inconsistencies with othe
 languages. So, I really don't think that we can avoid this problem.
 It's just a question of which form of it we want to deal with and how
 much code breakage we're willing to put up with to get it there.
[...] Maybe we should be considering *removing* from safe and nogc? But I don't see that flying either, since it can well conflict with existing user-defined identifiers. OTOH, I think there is some distinction between, say, pure and public, because pure is something that can be inferred, and it involves restricting the set of allowed code in the body of the function (likewise with nothrow, safe, nogc), whereas public merely affects external access to the function. The latter can't be inferred automatically (and it doesn't make sense to do so), but the former can. Furthermore, in the former case, it makes sense for a function's attributes to depend on its arguments -- e.g., opApply can be pure if the delegate argument is pure, but it doesn't make sense for opApply to be public/protected/private just because its argument is. So there's at least some amount of rationale for treating the two categories of attributes differently. T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Jun 21 2014
prev sibling next sibling parent reply Shammah Chancellor <email domain.com> writes:
On 2014-06-20 19:22:02 +0000, Brian Schott said:

 http://wiki.dlang.org/DIP64
 
 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too verbose
 2. New attributes use   and the old ones do not.
 
 I've created a DIP to address these issues.
I like it, but I think the attribute sets should be based on then alias syntax though. alias attributeSet = ( attribute1, attribute2, attribute3);
Jun 21 2014
next sibling parent reply "Temtaime" <temtaime gmail.com> writes:
Too many attributes in D.
In C++ there is no pure, safe, trusted and others.

And it's C++ that shows that almost all of D attributes are not 
necessary.

Welcome to attribute hell !
Jun 21 2014
next sibling parent reply "Chris Cain" <zshazz gmail.com> writes:
On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote:
 Too many attributes in D.
 In C++ there is no pure, safe, trusted and others.

 And it's C++ that shows that almost all of D attributes are not 
 necessary.

 Welcome to attribute hell !
Of course. But pure/safe/trusted/others statically verify that huge classes of errors cannot occur and make reasoning about code much easier. You're correct that it's not necessary, but they're certainly desirable in many ways. I'd willfully trade bug hell for "attribute hell".
Jun 21 2014
parent "Chris Cain" <zshazz gmail.com> writes:
On Saturday, 21 June 2014 at 18:11:32 UTC, Chris Cain wrote:
 On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote:
 Too many attributes in D.
 In C++ there is no pure, safe, trusted and others.

 And it's C++ that shows that almost all of D attributes are 
 not necessary.

 Welcome to attribute hell !
Of course. But pure/safe/trusted/others statically verify that huge classes of errors cannot occur and make reasoning about code much easier. You're correct that it's not necessary, but they're certainly desirable in many ways. I'd willfully trade bug hell for "attribute hell".
(well, "trusted" doesn't statically verify anything, it just makes it so you can manually verify the safety of the function so it can be used in safe functions, but you know what I mean)
Jun 21 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Temtaime:

 Too many attributes in D.
 In C++ there is no pure, safe, trusted and others.

 And it's C++ that shows that almost all of D attributes are not 
 necessary.
And C shows that most C++ features are not necessary. You can implement OOP manually, etc. Bye, bearophile
Jun 21 2014
parent reply "Temtaime" <temtaime gmail.com> writes:
We can try to emulate it, yes. But it results in bug-prone and 
'll ugly.
C++ gives more comfortable ways to implement things.

And attributes - it's only restrictions and gives almost nothing.
If you  don't want to play with pointers - just don't do it 
instead of writing  safe etc.
Jun 21 2014
next sibling parent reply "Chris Cain" <zshazz gmail.com> writes:
On Saturday, 21 June 2014 at 18:20:43 UTC, Temtaime wrote:
 And attributes - it's only restrictions and gives almost 
 nothing.
I'll reiterate that the restrictions in question make code easier to reason about. Increased reasoning is not "almost nothing" ... in fact, that's one of the main benefits of having any abstractions at all.
 If you  don't want to play with pointers - just don't do it 
 instead of writing  safe etc.
I think if you'd like a discussion about the values of the various attributes, you should create a topic about it. This topic should really only relate to this DIP. But FWIW, if what you said was truly sufficient, then there wouldn't be nearly as many bugs in C++ codebases as there are. Furthermore, there wouldn't be D, Go, Rust, Haskell, etc. and/or they wouldn't be found to be valuable by anyone.
Jun 21 2014
parent "Temtaime" <temtaime gmail.com> writes:
I think you misunderstood me.
I didn't say that C++ is useless and C can do all the things.
I spoken only about attributes.

D gives much more static checks and other great things.
And i'm unsure only at necessity of all these attributes.

In all my code i really uses only " const ", " immutable " and " 
 property ".
Jun 21 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Temtaime:

 If you  don't want to play with pointers - just don't do it 
 instead of writing  safe etc.
This is the C approach to programming, that has worked well enough for many years. Give the programmers all the sharp tools and let them sort out their usage and to follow sufficient safety measures. The result is an industry of code verifiers, tight code that runs fast, but sometimes fails very badly. Another approach is visible in Ada/Rust, safety on default enforced by the type system and the annotations. Ada works very well for its high integrity niche, while Rust is still unproven, but looks promising. D seems to follow an intermediate route. It's still not as safe as Ada/Rust, but it's somewhat safe and Walter shows that he wants D to become safer in future. Bye, bearophile
Jun 21 2014
prev sibling parent "francesco cattoglio" <francesco.cattoglio gmail.com> writes:
On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote:
 And it's C++ that shows that almost all of D attributes are not 
 necessary.
How so? Anyway, I totally agree that attributes NEED cleanup, it really makes zero sense to have some without " " annotation. Really, keep Scott's talk in mind! :P About code breakage: a sane deprecation path and an automated tool to make the code up-to-date will make sure there is zero discomfort for D users. The alias for the attribute set seems a very nice syntax to me.
Jun 21 2014
prev sibling parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 06/21/14 19:56, Shammah Chancellor via Digitalmars-d wrote:
 I like it, but I think the attribute sets should be based on then alias syntax
though.
 
 alias  attributeSet = ( attribute1,  attribute2,  attribute3);
Well, D does not have that kind of tuple syntax and introducing one for this special case wouldn't be a good idea. Other than that, this feature already exists, only it's currently limited to user defined attributes. The present syntax looks like this: alias Tuple(A...) = A; alias attributeSet = Tuple!(attribute1, attribute2, attribute3); and is already usable with UDAs and "magic" attributes: version (GNU) { static import gcc.attribute; enum noinline = gcc.attribute.attribute("noinline"); } struct other_attribute {} alias Tuple(A...) = A; alias spiffy = Tuple!(other_attribute, noinline); spiffy int f(int a) { return a+a; } I'm not sure inventing another syntax is necessary. (Making the built-in (keyword) attributes less special is of course the hard part, but the choice of syntax shouldn't really affect that) artur
Jun 21 2014
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2014-06-21 19:33:44 +0000, Artur Skawina via Digitalmars-d said:

 On 06/21/14 19:56, Shammah Chancellor via Digitalmars-d wrote:
 I like it, but I think the attribute sets should be based on then alias 
 syntax though.
 
 alias  attributeSet = ( attribute1,  attribute2,  attribute3);
Well, D does not have that kind of tuple syntax and introducing one for this special case wouldn't be a good idea. Other than that, this feature already exists, only it's currently limited to user defined attributes. The present syntax looks like this: alias Tuple(A...) = A; alias attributeSet = Tuple!(attribute1, attribute2, attribute3); and is already usable with UDAs and "magic" attributes: version (GNU) { static import gcc.attribute; enum noinline = gcc.attribute.attribute("noinline"); } struct other_attribute {} alias Tuple(A...) = A; alias spiffy = Tuple!(other_attribute, noinline); spiffy int f(int a) { return a+a; } I'm not sure inventing another syntax is necessary. (Making the built-in (keyword) attributes less special is of course the hard part, but the choice of syntax shouldn't really affect that) artur
So, basically we don't need special syntax for attribute sets, we just need to make it so built-in attributes are not "special?" -Shammah
Jun 22 2014
parent Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 06/22/14 14:18, Shammah Chancellor via Digitalmars-d wrote:
 
 So, basically we don't need special syntax for attribute sets, we just need to
make it so built-in attributes are not "special?"
I think this is one option. But exposing them as symbols w/o breaking too much existing code will not be trivial. Also, the parametrization and negation issues should probably be addressed at the same time, otherwise even more not fully backwards compatible changes may be necessary in the future. artur
Jun 22 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 20 Jun 2014 19:22:02 +0000
Brian Schott via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
I don't know. Why single out pure and nothrow? We also have public, final, static, const, immutable, etc. all of which don't start with . Only a very few of the attributes start with . So, it seems to me that changing pure and nothrow to pure and nothrow is really just moving the inconsistency around rather than fixing it. What's the point? The result is still inconsistent, and it's still arbitrary as far as I can tell. It's been suggested in this thread that this could help with attribute negation, but the primary attribute that we've discussed as needing to be negatable (final) is unaffected by this, so using as a way to lead to introducing attribute negation doesn't really work. And some of the existing attributes wouldn't make sense for negation (e.g. safe), because they're part of a group of three rather than two. And as for attribute sets, I think that they're the kind of idea that _sounds_ like a good idea but is ultimately a bad idea. Yes, having a function marked up like auto foo() const safe pure nothrow {...} is annoyingly verbose, but it's _clear_, and by adding attribute sets, we'd be opening the door to make it very unclear and confusing. If anyone can declare their own attribute sets, then we could end up with as many new names for attribute combinations as there are programmers using them. One person could create spn for safe pure nothrow, whereas someone else creats safepurenothrow, etc. And even if we created official attribute sets for the common stuff, you're still creating a combinatorial explosion of attributes that people have to know just so that they can put one attribute on a function instead of two to four attributes. I really don't think that that's a good tradeoff. I'd _much_ rather just leave things as they are. It may be verbose, but at least it's clear. I already think that it's bad enough that we have in on parameters being aliased to two different storage classes - const and scope. And now we're talking about not only adding _more_ items like that but making it so that _anyone_ can define them. I think that it's a far better idea to just have one way to mark something with a particular attributer rather than to find ways to combine multiple attributes into a single attribute. - Jonathan M Davis
Jun 21 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 20 Jun 2014 19:22:02 +0000
Brian Schott via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
I would point out that if we do this, we should serious consider renaming pure to noglobal rather than pure, or even making it the default and then adding global. That would make it so that we wouldn't have to keep explaining about how pure has very little to do with functional purity. - Jonathan M Davis
Jun 21 2014
prev sibling next sibling parent Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 06/22/14 08:26, Jonathan M Davis via Digitalmars-d wrote:
 I would point out that if we do this, we should serious consider renaming pure
 to  noglobal rather than  pure, or even making it the default and then adding
  global. That would make it so that we wouldn't have to keep explaining about
 how pure has very little to do with functional purity.
1) " noglobal" is probably not the best name; unfortunately I can't think of a good one... 2) Making it the default, when there are no safe escape hatches, would make things worse. You'd often end up having to go back and add ' global' annotations to the whole call stack, once it turns out to be necessary to use some D-impure code. Which can affect already published APIs etc. artur
Jun 22 2014
prev sibling next sibling parent reply Anonymous5 <rb.cssp nowhere.fi> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
exhumation So, two years after ? If attributes are well split into sub categories, we could justify that a sub category will have and another not (e.g protection attributes: not , functions attributes: ). The list of attributes that's not classified is: + static extern + abstract + final + override + synchronized + auto scope + const + immutable inout + shared __gshared + nothrow + pure ref possible categories: - function attributes: nothrow, pure - function member attributes: function attributes + abstract, final, override, static, synchronized , const , shared - type modifier attributes (+ return type attributes) function attributes and function member attributes can be replaced by a version. function attributes that are also type attributes will also have a new version but obsiously the not- version will always remain for <attribute>(T). type modifier attributes won't have a version because otherwise the goal of DIP is not reach (fix inconsistence for const for example which can have up to 3 different meaning now). This would reduce "the hell" a bit. --- rb.cssp nowhere.fi
Apr 17 2016
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On Sunday, 17 April 2016 at 12:05:03 UTC, Anonymous5 wrote:
 If attributes are well split into sub categories, we could 
 justify that a sub category will have   and another not (e.g 
 protection attributes: not  , functions attributes:  ).

 The list of attributes that's not classified is:

 + static
  extern
 + abstract
 + final
 + override
 + synchronized
 + auto
  scope
 + const
 + immutable
  inout
 + shared
  __gshared
 + nothrow
 + pure
  ref
Only override, nothrow and pure apply only to functions. Like the existing attributes, all function-only attributes should use attribute syntax. We only have to change 3, and the existing keywords can still be supported indefinitely IMO.
Apr 17 2016
prev sibling next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Nice. I like it.
Apr 17 2016
prev sibling next sibling parent reply Satoshi <satoshi gshost.eu> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Language defined attribs should be without and user defined attribs with Whats wrong with it?
Apr 18 2016
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Monday, 18 April 2016 at 10:32:39 UTC, Satoshi wrote:
 On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Language defined attribs should be without and user defined attribs with
It's already not the case with safe, trusted, system and nogc. They are not UDAs, they are defined in the language but they start with .
 Whats wrong with it?
- some attributes are also storage classes or type constructors (like const). - It looks strange when you learn. - It's confusing. - It's inconsistent in editors (lexing doesn't tells you what const is) If new attributes are added they'll always be something because there's already too much keywords in D. The first item in the list is interesting because people at the beginning often think that const int foo(){} returns a const(int), which is not the case. Here `const` is a function attribute, not a type constructor. The most insane case: const(int) foo(const int a) const { return 0; } Here it should be clear that const as a function attribute should be replaced by const.
Apr 18 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 18, 2016 10:32:39 Satoshi via Digitalmars-d wrote:
 On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Language defined attribs should be without and user defined attribs with Whats wrong with it?
We started putting on attributes to avoid adding new keywords before we even had user-defined attributes in the language. Hopefully, we don't need to add any new keywords, but if we do, we'd almost certainly do it with in order to actually avoid adding another keyword. Certainly, your suggestion is by far the most sensible from the standpoint of making it easy to figure out which attributes start with and which don't, but it would cost more keywords than we want to pay. Regardless, changing any of the attributes now would break a _lot_ of code, and such a change would have to be worth the pain that it would cause, which is questinonable. There isn't a consensus on what they should be changed to (pretty much any change except what you suggested results in inconsistencies in which ones are prepended with and which aren't - it's just a different set of inconsistencies that we have now, and that arguably defeats the whole purpose of making the change). There are definitely vocal folks who want the attributes changed in order to make them more consistent, but as long as it's not clear what they should be changed to, it'll never happen, and Walter and Andrei aren't big fans of renaming stuff just to make it more consistent. It carries a definite cost in terms of code breakage, and it's highly debatable as to whether it's worth it. So, I don't expect that the attributes are ever going to get renamed, though if someone can come up with a good enough scheme and somehow persuade Walter, then maybe it would happen. I'm not holding my breath though. - Jonathan M Davis
Apr 18 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 18 April 2016 at 12:11:46 UTC, Jonathan M Davis wrote:
 Regardless, changing any of the attributes now would break a 
 _lot_ of code, and such a change would have to be worth the 
 pain that it would cause, which is questinonable.
dfix has a DIP64 switch, right?
Apr 18 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 18, 2016 13:10:59 jmh530 via Digitalmars-d wrote:
 On Monday, 18 April 2016 at 12:11:46 UTC, Jonathan M Davis wrote:
 Regardless, changing any of the attributes now would break a
 _lot_ of code, and such a change would have to be worth the
 pain that it would cause, which is questinonable.
dfix has a DIP64 switch, right?
Yes, because the person who created DIP64 created dfix. But there is no consensus that DIP64 should be adopted, and based on how Walter has typically responded to changes that will break code, I very much doubt that having dfix make the change easy would be sufficient for him to decide that the code breakage that would result from changing the attributes would be acceptable. Honestly, I think that DIP64 is a poster boy for unnecessary churn. Sure, in theory, it would be nice to make the attributes more consistent, but ultimately, it's yet another case of renaming stuff without actually adding or otherwise changing functionality. We got enough screaming when we made changes like that 5 years ago even though they did make Phobos more consistent. And a _lot_ more code has been written since then. So, that much more code will be affected by such a change whether the change is theoretically desirable or not. And while having a tool to make the change relatively easy definitely helps, it doesn't eliminate the cost of the change. It just reduces it. Personally, I think that we're well past the point where doing renaming like this is worth it - especially with the language itself. - Jonathan M Davis
Apr 18 2016
prev sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Two years after, I think #1 would be a bad idea. I think it would overcomplicate most code for little benefit. Attributes aren't things that are easy to rally under a common name. Let's say that most people create their own set with " safe nogc pure"... what should it be called? " my_project_default"? Is there a name that would fit most projects so that many people can reuse it? Or will it have a different name for every project? In that case, not only would it complicate code reading, but what about mixing them? I foresee a *big* lot of issues with that for little benefit. However I do think that the current state of attributes is too complicated too. My take is that most people put the same attributes to almost every functions in a module because those functions are meant to work together. Therefore I think it would be more interesting to be able to set a new default for the module: default = safe nogc pure int foo(int i) { ... } // This function is safe nogc pure int bar(int i) pure { ... } // This function is only pure I haven't of course gotten to the point where I'm able to write a DIP but I think it's worth a thought. Attributes look heavy when they're repeated. Setting a default value is the thing to do because it's what would be done with sets anyway, and it makes functions that do not follow the default rule look more imposant which is good: anything aside normality should be well-advertised. About #2... come on, let's do it, consistency is a gift for the future. Of course code will break but it looks easy enough to fix.
Apr 18 2016
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Monday, 18 April 2016 at 19:57:42 UTC, cym13 wrote:
 On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
 http://wiki.dlang.org/DIP64

 Attributes in D have two problems:
 1. There are too many of them and declarations are getting too 
 verbose
 2. New attributes use   and the old ones do not.

 I've created a DIP to address these issues.
Two years after, I think #1 would be a bad idea. About #2... come on, let's do it, consistency is a gift for the future. Of course code will break but it looks easy enough to fix.
same, I neither do care about attribute sets but I'd like to see all function attributes will . Even with an abnormaly long deprecation cycle if it's necessary, not to afraid those who wants to remain in their comfort zone.
Apr 18 2016
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 18 April 2016 at 19:57:42 UTC, cym13 wrote:
      default =  safe  nogc  pure

     int foo(int i) { ... } // This function is  safe  nogc  pure
     int bar(int i)  pure { ... }  // This function is only  pure
Why not just put safe nogc pure: at the top? I feel like default would really only help if you want to write int foo(int i) default { ... } All things equal, I would probably prefer it as an alias alias default = safe nogc pure; The biggest downside with this approach is that there's not enough attributes. For instance, you can't write int bar(int i) system gc { ... } While system already exists, gc doesn't. I believe this has also been discussed before on NG. As an aside, the reason for not having function attribute inference everywhere is that it doesn't work when function bodies are not available. How common is this? I feel like I never write functions like this. Why not just make the rule that if the function body is available, then inference will happen?
Apr 18 2016
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 18 Apr 2016 20:49:45 +0000
schrieb jmh530 <john.michael.hall gmail.com>:

 As an aside, the reason for not having function attribute 
 inference everywhere is that it doesn't work when function bodies 
 are not available. How common is this? I feel like I never write 
 functions like this. Why not just make the rule that if the 
 function body is available, then inference will happen?
Just because you don't know about it doesn't mean it's non-existent. ;) Imagine we had LibreOffice and Gtk+ or some other library with many dependencies written in D. But even Phobos is a good start. If all function bodies were available for attribute inference that would start a cascade that requires the compiler to perform semantic analysis on all of LibreOffice, Gtk+ and whatever else is imported. It goes without further explanation that this doesn't scale and .di files have to be used at library boundaries. -- Marco
Apr 18 2016
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 18, 2016 20:49:45 jmh530 via Digitalmars-d wrote:
 As an aside, the reason for not having function attribute
 inference everywhere is that it doesn't work when function bodies
 are not available. How common is this? I feel like I never write
 functions like this. Why not just make the rule that if the
 function body is available, then inference will happen?
There is no guarantee that the source code will be available, so the attributes cannot be infered in the general case. In addition, if you don't make the attributes explicit, you have the problem that you have no idea which attributes apply to a function, which makes managing them harder and on some level defeats the purpose of having them. Another major problem is that if the attributes aren't explicit, then it's far easier to accidentally break code by accidentally changing the attributes. We pretty much had to add attribute inference to the language to make attributes and templates work together (since which attributes will work is often dependent on the template arguments), but normal functions don't need that inference. I would strongly argue that it's bad practice to rely on attribute inference when it's not required - even with templated functions. I'd even go so far as to argue that using labels like safe: or blocks like safe { } is generally bad practice, because it makes it harder to figure out which attributes apply to a given function, and while it might be nice to save on typing those extra characters for the attributes, you're causing more work for anyone who has to maintain those functions later - including yourself - because it's not immediately clear which attributes apply. - Jonathan M Davis
Apr 18 2016