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 "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
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 "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 next 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 "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 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
prev sibling 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 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
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
parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
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 "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 "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
prev sibling next 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 next sibling 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 next sibling parent 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
prev sibling next sibling parent 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
prev sibling next 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 "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
prev sibling 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 "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
prev sibling next sibling parent 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
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 next sibling parent "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
prev sibling next sibling 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 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 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
prev sibling next sibling 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 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 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