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

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

 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.



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.


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.





 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