Re: Why do some language-defined attributes have @ and some not?
On Friday, October 24, 2014 23:38:38 Chris Williams via Digitalmars-d-learn wrote: > On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby > > wrote: > > On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma > > via Digitalmars-d- > > > >> I submit that the syntax for attributes should be streamlined. > >> Shall I > >> go and open a Bugzilla item? > > > > No need: http://wiki.dlang.org/DIP64 > > Besides the @ symbols, isn't there also some inconsistency on > whether attributes go before or after the declaration? > > @property public static void foo() const @safe pure nothrow > > I've never bothered to ascertain how much of the positioning is > optional, but definitely none of it makes sense. Yeah. Some attributes are legal on both sides, others on only one, and I'm not aware of much logic to it (though at the moment, I don't think that there are any that are only legal on the right, so you could get away with just putting them all on the left). I think that it's primarily attributes that exist in other languages (and go on the left in those languages) that have to go on the left (e.g. public, private, static). Most (all?) of the D-specific ones can go on both sides. The ones that actually cause problems with that though are const, immutable, inout, and shared, because without parens, when they're put on the left, they still affect the function and not the return type, so quite a few of us have argued that they should be illegal on the left. - Jonathan M Davis
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby wrote: On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma via Digitalmars-d- I submit that the syntax for attributes should be streamlined. Shall I go and open a Bugzilla item? No need: http://wiki.dlang.org/DIP64 Besides the @ symbols, isn't there also some inconsistency on whether attributes go before or after the declaration? @property public static void foo() const @safe pure nothrow I've never bothered to ascertain how much of the positioning is optional, but definitely none of it makes sense.
Re: Why do some language-defined attributes have @ and some not?
On Friday, 24 October 2014 at 15:06:25 UTC, Ola Fosheim Grøstad wrote: I agree that "@"-stuff is trivial, but I don't think Python sets a good example. The codebase is basically divided in two, libraries have to support both, and I think they should have changed more if going to the trouble. Yes, Python has a real problem with this. I would like to see a proper deprecation path implemented in D. I don't want my code breaking but i'm willing to accept *informed* deprecation, followed by removal. Even if this process takes place over a few years.
Re: Why do some language-defined attributes have @ and some not?
On Friday, 24 October 2014 at 14:23:04 UTC, Shriramana Sharma via Digitalmars-d-learn wrote: As for the cases when serious changes to the grammar are needed, I feel the Py2 to Py3 transition is a good example to emulate. Lots of cleanup happened in Py3, Py2 is still supported, and there exists tools like 2to3 and six (https://pypi.python.org/pypi/six) to help people bridge the gap. I agree that "@"-stuff is trivial, but I don't think Python sets a good example. The codebase is basically divided in two, libraries have to support both, and I think they should have changed more if going to the trouble. In essence you should either change so little that upgrading is trivial or you should improve the language enough to ensure that all new projects choose the improved language. However, Python is in widespread use on a fairly massive scale and is dynamic, which makes breaking very serious as it happens at runtime. D could with little trouble undergo a massive change where the static type system catch the issues and call it D3. The real problem is that there is no design for a D3 rooted in a semantic model that is clean. Such a transition would require a solid formal specification where you eliminate all weird aspects. But I don't think anyone is working on a new spec? I am willing to help out if other people are interested.
Re: Why do some language-defined attributes have @ and some not?
Hi people and thanks for weighing in. It's nice to note that there's already a DIP on this. I hope it's refined and implemented in a future version in a meaningful manner. Is it OK to edit the wiki to add one's opinions? And in this case, personally I'm not sure why people are talking about code *breakage*, which is a big word IMO. It's after all removing or adding @ in a few cases. It's relatively straightforward a fix to automate. If there can be a dfix to relocate the const from before to after the function name, then this should be much easier, no? It wouldn't even need a D3, but could be done in a future D2 point release. And as someone else said, there's a difference between outright breakage and planned deprecation. As for the cases when serious changes to the grammar are needed, I feel the Py2 to Py3 transition is a good example to emulate. Lots of cleanup happened in Py3, Py2 is still supported, and there exists tools like 2to3 and six (https://pypi.python.org/pypi/six) to help people bridge the gap. Finally in general I'd also like to suggest that rather than saying something like "you won't be able to convince Walter of this because it's not important", which IMHO tends to somewhat put off newbies who are excited by the language and want to contribute, and tends to put the project masters in an autocratic light (which people won't like to hear), one might consider saying something like "D 2 is now aiming for stability so we are trying to minimize the number of grammar changes". Thanks again, all! -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Why do some language-defined attributes have @ and some not?
On Friday, October 24, 2014 08:19:48 Paolo Invernizzi via Digitalmars-d-learn wrote: > On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote: > > There are people out there using D who do not participate in > > the newsgroups. Walter has told us before that he gets emails > > from companies using D in production. He has to deal with > > complaints about code breakage that we aren't going to see here > > in the NG. Just keep in mind that no matter how many of us here > > agree on a breaking change, we are not the entirety of the D > > user base. And it has nothing to do with Reddit. > > I think that Walter talked about emails complaining about "silent > breakage" or "regressions", and that's a totally different matter. > > To be honest, I only remember that he talked about one single > case, but maybe I'm wrong. > And I don't remember any complain about code deprecations. Walter doesn't seem to understand that unintended breakage and planned, communicated breakage via a proper deprecation process are two totally different issues. He's definitely had folks complain about regressions, and the response to that has sometimes been that changes that we were considering got axed, because he'd just had someone complain about (unintended) code breakage, and for him, that meant that pretty much _anything_ which would eventually result in code breakage was bad and therefore raised the bar on changes that much more (IIRC, that happened just after the virtual keyword had been introduced, and the result was that it was removed, and the plans to switch to final by default were axed). So no, I don't think that folks have complained to him about deprecations (though they could have, and he just never said anything about it), but they have complained often enough about other stuff, and he doesn't seem to distinguish between planned breakage and unintentional breakage in the same way that many of the rest of us do. - Jonathan M Davis
Re: Why do some language-defined attributes have @ and some not?
On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote: There are people out there using D who do not participate in the newsgroups. Walter has told us before that he gets emails from companies using D in production. He has to deal with complaints about code breakage that we aren't going to see here in the NG. Just keep in mind that no matter how many of us here agree on a breaking change, we are not the entirety of the D user base. And it has nothing to do with Reddit. I think that Walter talked about emails complaining about "silent breakage" or "regressions", and that's a totally different matter. To be honest, I only remember that he talked about one single case, but maybe I'm wrong. And I don't remember any complain about code deprecations. --- /Paolo
Re: Why do some language-defined attributes have @ and some not?
On 10/24/2014 7:20 AM, ketmar via Digitalmars-d-learn wrote: why can't i see that J. Random in recent discussion about deprecating prefix 'const'? the universal answer was: "yes, break our code NOW! PLEASE!" including people from the companies with big D codebases. There are people out there using D who do not participate in the newsgroups. Walter has told us before that he gets emails from companies using D in production. He has to deal with complaints about code breakage that we aren't going to see here in the NG. Just keep in mind that no matter how many of us here agree on a breaking change, we are not the entirety of the D user base. And it has nothing to do with Reddit.
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 22:20:28 UTC, ketmar via Digitalmars-d-learn wrote: i love D and i want D to be widespread, but what makes me love D is it's attitude to fixing stupid legacy we have in C and C++. and now it seems to me that someone should start "BetterD" project to fix legacy we already have in D. ain't the desire to fix legacy cruft was one of the big driving forces of D creation? it's a pity for me to see that D starting to follow some of the worst C++ aspects. _Every_ language ends up with legacy cruft if it ever gets any kind of widespread use in the real world. If you want a language that never has legacy cruft, I expect that you will be forever disappointed. The question is what is and is worth changing and at whether you ever reach the point that you're _never_ allowed to break code (which is pretty much where C++ is). I certainly hope that D never reaches the point that we'll never break code even when it truly makes sense to do so, but we _have_ reached the point where the reasons have to be much stronger. Some stuff that could currently be considered legacy cruft will probably be changed, but it's generally a hard sell, particularly because Walter is _very_ paranoid about breaking people's code (arguably too much so). Though it should be noted that the vast majority of D users never post in the newsgroup, and many of them probably have never visited it, so basing anything on what's discussed in the newsgroup is basing it on the most dedicated users, which aren't necessarily representative of the user base sa a whole, which always makes it difficult to figure out which decisions that would break code are okay and which aren't and is probably part of why Walter overreacts to some of the comments on places like reddit. Regardless, you can certainly try and lobby for the attribute names to be normalized, but I don't expect it to change, in this particular case, while I'd certainly be open to it if Walter want to get rid of all of the @s on all of the built-in attribute names, I also don't really care if they stay the way they are. It's a minor annoyance, but I never found it hard to learn which ones had @ on them and which didn't (just treat it like one extra letter to learn in the keyword), and I'm light years beyond the point where I memorized them all. The primary annoyance about it at this point is having to answer questions on it when yet another user tries to figure out why some have @ and some don't as if there's a discernable pattern to it, and there isn't. And that sucks, but it doesn't actually cause bugs (unlike allowing const on the left-hand side of a member function, which definitely should be deprecated), and it's actually pretty easy to explain. - Jonathan M Davis
Re: Why do some language-defined attributes have @ and some not?
On Thu, 23 Oct 2014 21:33:00 + Jonathan M Davis via Digitalmars-d-learn wrote: > On Thursday, 23 October 2014 at 07:54:05 UTC, ketmar via > Digitalmars-d-learn wrote: > > On Thu, 23 Oct 2014 07:47:00 + > > via Digitalmars-d-learn > > wrote: > > > >> On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via > >> Digitalmars-d-learn wrote: > >> > besides, no "serious" language can live without "legacy". > >> > legacy is a sign of maturity. ;-) > >> > >> So you are basically saying that D is a teenager for whom > >> wearing ugly make-up is a sign of maturity? > > exactly. it seems to me that some D developers have strange > > feeling > > that accumulating legacy will show D maturity and will help D > > to become > > more widespread. despite all "#breakourcode" requests from real > > D users. > > I would be very surprised if anyone thinks that. It's a question > of what breakage is worth making and the fact that every time we > break people's code, we risk ticking users off and scaring them > away. It doesn't work to become widespread - particularly in > production - when you frequently break people's code (even with a > good reason), and breakage needs a good reason even when it's > rare. and those poor souls who already commited to D often just can't run away, so they can stand alot annoying things, even if they praying to break their code. this is J. Random, The Reddit User who really matters. J. Random never used D for anything more complex than "hello, world", but maybe he will write another "hello, world", and if we'll change that inconsistent feature, which annoys alot of actual users, J. Random will scream in pain! even if "changing the feature" means at least one year of deprecation first, and J. Random's "hello, world" will work for this year, and compiler will guide him in fixing his code. why can't i see that J. Random in recent discussion about deprecating prefix 'const'? the universal answer was: "yes, break our code NOW! PLEASE!" including people from the companies with big D codebases. will it help if we'll start reddit campaigns instead of trying to talk in this NGs? seems that J. Random The Reddit User has much more influence on decisions like that. > Deciding whether a particular change is worth making is > always a subject of big debate. ...and then someone will come and say: "no, we won't do that despite anything you wrote here." > There _are_ cases where most > everyone agrees and yet Walter won't make the change, but there > are also plenty where there definitely isn't a consensus. For > attributes, there's a consensus that the situation is not ideal, > but there definitely isn't a consensus on what we should do about > it or whether it's worth breaking code to fix it. i bet alot of people just tired of endless talking which leads nowhere. heh, the strongest argument that can stop almost any discussion is "well, try to convinve Walter". Walter is very talented person, he's great person, and he is open to discussion, but it seems to me that he has very solid picture of what he wants D to be and don't want to change small things that are OK for him, but annoying for others. but those "small issues that barely worth changing" tend to accumulate and hurt the whole language. > And because > it's pretty much an aesthetic thing, it's exactly the sort of > thing where it would be very difficult to convince Walter or > Andrei to make the change (especially Walter). Making the change > won't fix any bugs and won't prevent any bugs, so it's a hard > sell. yes, that things just making life a little easier for D users. take me, for example: i still can't remember where i should put that '@' and where i shouldn't. it's not on top of my fingers and it has no logic behind, so trying to remeber such thing breaks me out of my "thinking stream". and this is so easy to fix that this annoys me each time. and while it left unfixed, we accumulating more and more D code, making fixing this thing in future close to impossible, 'cause it will really break huge codebases. aestetic things matters alot. > Regardless, no one is actually aruging that we want to leave any > kind of legacy cruft in the language just so that we have legacy > cruft and therefore look mature. yes, i'm sarcastic when saying this, and when i'm saying that "existing D users are second-class citizens", but how else can i show that this issues *matters* *alot*? > and because we are very much trying to make it so that D > is mature enough to be used in production people from companies which using D tells that it will be good to make some code-breaking change and this change will made their codebases easier to maintain and will make code from new developers less error-prone. and... they are mostly ignored. so it seems to me that having some useless legacy is the only way to sell D to some "enterprise production". > the bar that something has to pass in order to be > considered worth changing (part
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 07:54:05 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 23 Oct 2014 07:47:00 + via Digitalmars-d-learn wrote: On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via Digitalmars-d-learn wrote: > besides, no "serious" language can live without "legacy". > legacy is a sign of maturity. ;-) So you are basically saying that D is a teenager for whom wearing ugly make-up is a sign of maturity? exactly. it seems to me that some D developers have strange feeling that accumulating legacy will show D maturity and will help D to become more widespread. despite all "#breakourcode" requests from real D users. I would be very surprised if anyone thinks that. It's a question of what breakage is worth making and the fact that every time we break people's code, we risk ticking users off and scaring them away. It doesn't work to become widespread - particularly in production - when you frequently break people's code (even with a good reason), and breakage needs a good reason even when it's rare. Deciding whether a particular change is worth making is always a subject of big debate. There _are_ cases where most everyone agrees and yet Walter won't make the change, but there are also plenty where there definitely isn't a consensus. For attributes, there's a consensus that the situation is not ideal, but there definitely isn't a consensus on what we should do about it or whether it's worth breaking code to fix it. And because it's pretty much an aesthetic thing, it's exactly the sort of thing where it would be very difficult to convince Walter or Andrei to make the change (especially Walter). Making the change won't fix any bugs and won't prevent any bugs, so it's a hard sell. Regardless, no one is actually aruging that we want to leave any kind of legacy cruft in the language just so that we have legacy cruft and therefore look mature. It comes down to whether fixing that legacy cruft is worth it when everything else is taken into account, and because we are very much trying to make it so that D is mature enough to be used in production and gets wider adoption, the bar that something has to pass in order to be considered worth changing (particularly by Walter) is much, much higher than it would have been a few years ago. - Jonathan M Davis
Re: Why do some language-defined attributes have @ and some not?
On Thu, 23 Oct 2014 07:47:00 + via Digitalmars-d-learn wrote: > On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via > Digitalmars-d-learn wrote: > > besides, no "serious" language can live without "legacy". > > legacy is a sign of maturity. ;-) > > So you are basically saying that D is a teenager for whom wearing > ugly make-up is a sign of maturity? exactly. it seems to me that some D developers have strange feeling that accumulating legacy will show D maturity and will help D to become more widespread. despite all "#breakourcode" requests from real D users. signature.asc Description: PGP signature
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via Digitalmars-d-learn wrote: besides, no "serious" language can live without "legacy". legacy is a sign of maturity. ;-) So you are basically saying that D is a teenager for whom wearing ugly make-up is a sign of maturity?
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma via Digitalmars-d- I submit that the syntax for attributes should be streamlined. Shall I go and open a Bugzilla item? No need: http://wiki.dlang.org/DIP64
Re: Why do some language-defined attributes have @ and some not?
On Thu, 23 Oct 2014 06:29:12 +0530 Shriramana Sharma via Digitalmars-d-learn wrote: > I submit that the syntax for attributes should be streamlined. Shall I > go and open a Bugzilla item? hehe. https://issues.dlang.org/show_bug.cgi?id=13388 https://issues.dlang.org/show_bug.cgi?id=13397 i must admit that there were NO "code breaking" in both of that, and in NG discussion people telling about newcomers asking "why that '@' is here but not there". besides, no "serious" language can live without "legacy". legacy is a sign of maturity. ;-) signature.asc Description: PGP signature
Re: Why do some language-defined attributes have @ and some not?
On Thu, Oct 23, 2014 at 10:50:07AM +0530, Shriramana Sharma via Digitalmars-d-learn wrote: [...] > So I agree with you that for now this is not an urgent need. I guess > when we clean out all that !> <>= stuff this can be done too, or > something like that... [...] I believe those flying-saucer operators (:-P) are slated for removal. IIRC, Walter has recently actually made some PRs to deprecate those operators, which means in a couple o' releases they should finally be gone for good. T -- Shin: (n.) A device for finding furniture in the dark.
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 02:22:41 UTC, Jonathan M Davis wrote: On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma via Digitalmars-d-learn wrote: LOL. I understand the sentiment, but it's a waste of time. Jonathan, I agree It's impossible to debate such thing with Walter / Andrej right now, but I don't think It's a waste of time: every explicit and accountable opinion about that is a little stone to weigh in the balance. --- /Paolo
Re: Why do some language-defined attributes have @ and some not?
On 10/23/14, Jonathan M Davis via Digitalmars-d-learn wrote: > So, yes, we do have historical baggage, albeit nowhere near as > much as C++ does. OK understood, but I may just go and file that bug so that if there is a future D 3 series, then stuff like this can be cleaned up. :-) I'm finicky like that! ;-) > Walter and Andrei very much want D to be being used in production > at this point, We all do, no? Not only those two! :-) So I agree with you that for now this is not an urgent need. I guess when we clean out all that !> <>= stuff this can be done too, or something like that... -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Why do some language-defined attributes have @ and some not?
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma via Digitalmars-d-learn wrote: I thought D was beyond carrying historical baggage. DMD 2.x is not necessarily language-compatible with DMD 2.(x+1) since the language is still evolving. You can deprecate one syntax and enforce the other in a later version. I submit that the syntax for attributes should be streamlined. Shall I go and open a Bugzilla item? LOL. I understand the sentiment, but it's a waste of time. We've long since reached the point where we try and not break people's existing code unless we have a really good reason for it (and for better or worse, aesthetics definitely don't make the cut). No, D2 is not as fixed in stone as C++ is, but we are trying to have a stable enough language for programmers to use in production rather than treating the language as being experimental and/or rapidly changing in incompatible ways. So, yes, we do have historical baggage, albeit nowhere near as much as C++ does. But the reality of the matter is that _every_ language that gets used in production has historical baggage, because you never get everything right, and you frequently can't afford to change it, because it would break too many existing programs. And for better or worse, fixing attribute names doesn't even come close to being on the list of things that Walter Bright would consider worth changing. It's hard enough to get him to agree to make breaking changes when most of us agree that we'll be better off with the changes in spite of the code breakage that they cause, let alone on a controversial topic like attribute names which has been discussed to death. Walter and Andrei very much want D to be being used in production at this point, and so the focus on features is entirely on what's required to make the language fully usuable for companies looking to use D, and tweaking things to make them cleaner just isn't going to happen without a really good, practical reason for it. Breaking changes are sometimes made still, but not for something like that - Jonathan M Davis
Re: Why do some language-defined attributes have @ and some not?
I thought D was beyond carrying historical baggage. DMD 2.x is not necessarily language-compatible with DMD 2.(x+1) since the language is still evolving. You can deprecate one syntax and enforce the other in a later version. I submit that the syntax for attributes should be streamlined. Shall I go and open a Bugzilla item? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Why do some language-defined attributes have @ and some not?
On Wednesday, 22 October 2014 at 19:13:58 UTC, Shriramana Sharma via Digitalmars-d-learn wrote: Hello. See http://dlang.org/attribute. 3 attributes starting at http://dlang.org/attribute#disable have a @ in front. Apparently safe, trusted and system also do, though these are documented elsewhere: http://dlang.org/function.html#function-safety. Why are some language-defined attributes starting with @ and others not? Wouldn't it be consistent and less-confusing to, say, only use @ for user-defined attributes and not these language-defined ones? It's a historical thing. Walter didn't want to add more keywords, so we put @ in the front of some of the new ones. User-defined attributes didn't even exist at the time. Those were added far later. It would be nice if none of the built-in attributes had @ on them, but it's far too late now. And by the way, there's also @property, so there's four of them with @. - Jonathan M Davis
Why do some language-defined attributes have @ and some not?
Hello. See http://dlang.org/attribute. 3 attributes starting at http://dlang.org/attribute#disable have a @ in front. Apparently safe, trusted and system also do, though these are documented elsewhere: http://dlang.org/function.html#function-safety. Why are some language-defined attributes starting with @ and others not? Wouldn't it be consistent and less-confusing to, say, only use @ for user-defined attributes and not these language-defined ones? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
