Bug 13388 – accept '@' before 'nothrow' and 'pure'

Created attachment 1391 allow UDA-like syntax for some keyword attributes there is some inconsistency between UDA-like attributes like '@trusted', '@nogc' and so on and non-UDA-like attributes like 'pure' or 'nothrow'. we can't force using UDA-syntax for latter, but we can at least allow it, so user shouldn't remember that 'nothrow' is a keyword and '@safe' is an attribute. this patch allows using some keyword attributes as UDAs. i.e. user can write: void foo () @safe @nothrow @pure { … } old syntax is supported too: void foo () @safe nothrow pure { … } so no code will be broken.

Despite being "more syntax" I'm very much in favor of this change. It makes it that much easier to remember which attributes need or don't need the at sign. I frequently make the mistake of miss-tagging due to the current situation.

Created attachment 1392 testcase: must compile

Created attachment 1393 testcase: must fail with "'mustf.foo' is not nothrow"

I'm very much against this because then it's possible to have both nothrow and @nothrow in code (and the same for the others), and that's just going to create confusion. Right now at least, it's clear when you get it wrong, because you get a compilation error, but if we allowed this, then many users won't know the difference between the two, and confusion and questions will ensue. I really think that they should be one way or the other and not both. In addition, it's not like this makes everything consistent, because attributes like static or const wouldn't ever have @ on them. If this change were forced, all it would do is move some of the attributes from keywords to the @ side - it wouldn't actually make them all consistent- and making it so that you _can_ mark some of them with @ but don't have to is just going to increase confusion and inconsistencies between programs. This isn't just not worth it IMHO; it's detrimental.

i can't see why we can't turn const to '@const' too. this will remove long-standing 'const confusion': '@const' can be only function attribute. i didn't do it in this patch 'cause i believe that it's two very different changes, and '@const' patch has no sense without this patch. about 'static': this is not an 'attribute' like 'nothrow', 'cause we can't write: void bar () static {} (why, btw?) i agree that enforcing '@' syntax is The Right Thing, but this will break alot of code. allowing '@' is a little step towards consistency. yes, it makes some mess, but it will allow to deprecate non-UDA attributes in the future. i believe that turning D in C++ with "ah, we know about this inconsistent crap, but it's our legacy and we have to live with it" will harm D in the long run. language that trades developement for stability will become C++. current attribute syntax is a mess. let's clean it up: first by allowing two syntaxes (ok, it's confusing, but leaves some time to fix the old code) and then by deprecating non-UDA syntax. if we will not do the first, we will never do the second.

(In reply to Ketmar Dark from comment #5) > about 'static': this is not an 'attribute' like 'nothrow', 'cause we can't > write: > > void bar () static {} > > (why, btw?) public, private, etc. are in the same boat: https://issues.dlang.org/show_bug.cgi?id=12930 The attributes are treated consistently in general, which sucks, and I think that the placement issues can and should be fixed, but I don't think changing any of the attributes to @ is even vaguely worth it, especially considering the resulting code breakage (not to mention, it's very ugly for them all to start with @ IMHO). Just think of the @ as part of the name, and the inconsistency goes away anyway, since then you just have some attributes which happen to start with the same character, just like happens with attributes like private and public. With that line of thought, complaining about some attributes starting with @ and some not would be like complaining that some attributes started with p and some didnt'.

> Just think of the @ as part of the name, and the inconsistency goes away anyway no, it's not. it's ok to remember *words*, but it's not ok to remember which word should be prepended with 'sigil'. it can be ok for attributes with meaningless names. there is really no much difference between '@riogjheo' and 'riogjheo' — they both sux and hard to remember. but making some *words* special… why '@safe' needs '@' and 'pure' don't? what is so special about the word 'pure' (or 'safe')? why should i remember this nonsence? ok, we can go another way: strip out all '@' from compiler-defined attributes. and we can do this without introducing new keywords — just forbid prefix attributes. so void foo () system; will not require "system" to be a keyword, and we can declare and use variables with the name 'system' in other code. this patch is little more intrusive, but i can try to write it. do you think that it will be better alternative to this one?

I don't think this is a good idea because: - It goes against the rule that there should be only one obvious way to do something; - It's a change that introduces nothing new that is useful in D; - It will increase the frequency of the '@' symbol in D source code, that I find noisy to read and not easy to write with my keyboard; - This topic was discussed a lot (tens or hundreds of posts) in past when @trusted, @safe and @system were introduced. I don't think there are new points to be added now. So I vote for wontfix.

ok, i did it another way: https://issues.dlang.org/show_bug.cgi?id=13397 this time we can omit '@' before postfix attributes. ;-)

I think this should be looked at in terms of conceptual differences between the attributes using keyword notation, vs. those using @-prefix notation, as well as compliance to C compatibility. For instance, why are static, const, immutable, final, shared, __gshared, and deprecated, keywords, while @property, @safe, @trusted, @system, @disable, and @nogc, are UDAs? What is the underlying conceptual difference here that necessitates the separation? I'm not sure anyone really knows, and that's why we have this problem in the first place. I think we can safely say that const, static, public, protected, private, etc are keywords to conform to C/C++ code-style, but what about the rest? The following is what I'd do given the option, and what would be (IMO) a great system to adopt in the language, but this is just my opinion and I'm sure others would disagree: Keywords: extern, align, package, private, protected, public, export, pragma, static, extern, abstract, final, synchronized, auto (shouldn't this be a type?), scope, const (shouldn't this be part of the type?), immutable (shouldn't this be part of the type?), inout, shared, __gshared, property, and ref (shouldn't this be part of the type?). UDAs: deprecated, override, nothrow, pure, safe, trusted, system, disable, nogc. In terms of a general solution, I see it as though we have 4 options: 1) Resolve the inconsistency through community engagement and voting (ala. democracy) 2) Resolve the inconsistency by going all or nothing in either direction (i.e. all UDAs or all keywords) 3) Define the requirements/rational for attributes to exist in one category vs. the other, so that developers have a conceptual grounding when trying to rationalize the difference 4) Allow either notation for either some or even all of the attributes, documenting the idiomatic way, and let the developers ultimately decide Given that there seems to be a detrimentally-large resistance to breaking changes in the language (which is a little concerning in itself), I see option 4 as the only reasonable way forward. @Jonathan: I understand your angle with regard to user confusion, but given the alternatives are either never ever fixing this, or breaking changes, are you sure you'd rather go down the route of never fixing this? User confusion can be addressed by making appropriate documentation for this change. I.e. State in the documentation that the idiomatic way is to use @-style notation, but that not including it also works for legacy reasons. Done. Old code doesn't break, and new users will have to read the documentation anyway. @bearophile: On only doing things one true way, see here why this argument makese no sense: http://dlang.org/pragma.html#Pragma On not adding anything useful to D, I disagree. Fixing this issue in some way or another adds consistency and elegance to the language. When I show people D code, almost invariably people say things along the lines of "Why does property require the @-symbol, where as nothrow doesn't?", followed immediately by "Eww, well that just looks ugly.". In my experience, it's a build-up of little dirty bits here and there that wards off adoption of a new language with most people, because it means they're forced to *look at* the problems with the language, and often can't get past that even when shown the best features of said language. D should strive to fix things like this, because if the syntax is absolutely clean and elegant, then at least people won't have to *look at* problems in the language.

(In reply to Trey Brisbane from comment #10) > On only doing things one true way, Adding to D more ways to do something in an "equally obvious" way is bad. > Fixing this issue in some > way or another adds consistency and elegance to the language. Having contextual keywords or two different ways to spell a keyword is the opposite of elegance. > When I show > people D code, almost invariably people say things along the lines of "Why > does property require the @-symbol, where as nothrow doesn't?", followed > immediately by "Eww, well that just looks ugly.". Fixing this is probably going to cause bigger problems. For me your solutions are worse than the current problem. > D should strive to fix things like this, Keep in mind that this topic was discussed a lot. I don't think the situation will change now. (I'd like the default to be const, pure, nothrow, and "mut" to be a keyword :-) But such things will not happen.)

Then what is your alternative proposal?

(In reply to bearophile_hugs from comment #11) > Adding to D more ways to do something in an "equally obvious" way is bad. is there another way to change this without breaking existing code? people will have time to fix their code, and then we can deprecate and kill old syntax. > Keep in mind that this topic was discussed a lot. yet people keep asking about it. it's a clear sign that the problem is present, and it can't be solved by just ignoring it. ah, sure, it can be solved by force of course: "eat it or GTFO!" so we can keep ignoring it and eventually it will turn into "time-blessed legacy; alas, we can't do anything with it now". i know the language that ridden with such things… that's why i don't want to use C++ anymore.

Honestly, at this point, I think that we should just leave the attribute names as they are now. It's just not worth it to mess with them. Maybe we should have just made them all keywords to begin with, but that ship sailed a long time ago. It's really not that hard to remember which attributes have @ at the front of their names. Changing the situation would just break code, and if we did it by adding @ to more attributes, we'd just end up with more complaints about the ugly @'s and questions why we have @public or @const or whatever when other languages don't put the @ in front of them. While something cleaner would be nice, I really think that we've passed the point where it's worth fixing it.

(In reply to Jonathan M Davis from comment #14) > I really think that we've passed the point where it's worth fixing it. so we can tell newcomers that D is very mature language. "see, we have unfixable legacy syntax, just like C++! how dare you to say that D is not stable?!" ;-)

Frankly, this is a problem. Problems should be fixed. With attribute syntax, there are cross-cutting concerns... Static is an attribute that fundamentally changes the semantics of the method it's on. Pure, is an attribute that ensures the function does not touch global state. But that's kinda just saying "This is my intent. Please check that for me.", rather than any real semantic change. In my opinion, pure should be an annotation, but it's a keyword. When I, and I'm sure many others, write code, I like to separate out annotations and place them above the method declarations, but I can't do this effectively in D because some are keywords, and so there's no logical separation that facilitates elegant code. If we only look at this issue in isolation, the payoff is small for a relatively intrusive change. But if we look at the bigger picture of this issue along with the many other small issues that aren't going to get fixed under the current mindset, then by fixing it we move one step closer towards a better language that will ultimately be more attractive to more users.

Every language ends up with legacy stuff that folks might like to fix but can't. There's no way around that. It's just a question of when. Sure, we've fixed a lot with D, but its usage is increasing, which increases the cost of changing things considerably, and these changes are essentially aesthetic. _Maybe_ they would make learning the attributes slightly easier, but the change would not actually improve D programs at all. You can bring up this sort of thing and push it as much as you want, but I would be shocked if you ever convinced Walter and Andrei that this is a good idea. They're likely to be even firmer than I am that this is a waste of time and detrimental to the language. They'll view this like they view function renaming and will be completely against it. And it's not like this is the first bit of legacy muck that we have to deal with. For instance, ff we could make whatever changes we wanted, then we'd do things like make @safe and pure the default, but it's far too late in the game to make those changes. D isn't fixed in stone yet, but a change has to pull its weight to be worth making everyone change their code, and that cost is just increasing with time as the number of users increases. And an aesthetic improvement just doesn't make the cut anymore.

seems that it's time to fork into "D refurbished" project. ;-) no, really, it's only a half-joke…

For a language that was conceived to address issues exactly like this in languages like C++, I think that's a pretty poor view to take. Functional changes (new features, fixing bugs, etc) are obviously of great importance, since they alter the ability of users to actually get work done. Aesthetic changes (syntax alteration, function renaming, etc) are what you do early in a languages life-span in order to make working with the language for new users *as pleasurable as possible*. D2 is less than 8 years old, and you're telling me that a problem, that I have directly observed turn potential new users away from the language, is going to be ignored into the future simply because it is an aesthetic change? This is despite the fact that you have at least two people here willing to take the time to make the required changes (one of whom has already submitted candidate patches), and provide as easy an upgrade path as is possible? That we could write highly-informative deprecation messages, or a compiler-flag to essentially auto-upgrade code to conform to the changes, or simply allow for an alternative, and none of these are good enough? That is silly, I'm sorry to say. I would understand it if Walter or Andrei themselves were tasked to work on it, because yes, that would be a waste of time. But when you have at least two people sitting here willing to make the contribution and you're turning them down simply because "lol aesthetic change", how can you expect the wider community to take the time to contribute when the over-arching mentality nowadays seems to be "haha good luck getting your change accepted"? No, time is not a valid excuse. We are here, and we are willing to do what is required to fix this problem one way or another. Is D really at the stage where we're turning away contributors because "oh god we might lose a few precious users who don't understand that a relatively new language might have breaking changes"?

Who does the work is irrelevant. It's the fact that it will break code for marginal benefit. I'm done discussing this. I've made my views clear. Regardless of what I think on the matter, it's Walter and Andrei that you have to convince, and I would be shocked if you could. Increasingly, they're of the opinion that breaking changes aren't worth it at this point in the game. So, any breaking change that we make must bring a large benefit. The result of that is that things like renaming functions - or function attributes - are no longer considered to be worth the cost. Walter in particular considers it to be just shuffling things around and highly detrimental to the language. If you want the attribute situation changed, then find a way to convince Andrei and Walter. Without that, it'll never happen.

I have to agree with Jonathan here, and am strongly against this. While I can see an argument for it to be accepted before nothrow and pure, there's no reason it should be accepted before final, abstract, or override. Nothrow and pure are attributes that effectively constrain what can be inside the method, where-as final, abstract, and override all functionally effect the program.

Ketmar, what was your rational for including final, abstract and override in this patch? Would you guys be more receptive to the idea if it was just nothrow and pure being affected?

Created attachment 1400 allow UDA-like syntax for 'pure' and 'nothrow' (In reply to Trey Brisbane from comment #22) > Ketmar, what was your rational for including final, abstract and override in > this patch? parser checks for 'em all in the same place, that's it. ;-) ah, and to be consistent with '@property'. > Would you guys be more receptive to the idea if it was just nothrow and pure > being affected? attached new patch. only 'pure' and 'nothrow' can be prefixed with '@' now. and fixed one bug.

Created attachment 1401 allow UDA-like syntax for 'pure' and 'nothrow' to remember: don't attach patches without proper checking. attached correct patch this time.

Created attachment 1402 testcase; must compile

Created attachment 1403 testcase; must fail with "'mustf.foo' is not nothrow" and "function 'mustf.bar' is nothrow yet may throw"

>(In reply to Jonathan M Davis from comment #14) >> I really think that we've passed the point where it's worth fixing it. NO!!!! This attitude is the biggest problem D has. Please, watch Scott Meyer's talk again. "Most D code is yet to be written". The future benefits of fixing this kind of crap, are huge. And this one doesn't even break any existing code. Omitting the @ from pure and nothrow was heavily criticized at the time. It was known to be a stupid decision. Two things have changed since then: (1) We now have UDAs. (2) @property is gone. Now, the existence of @property was the only decent argument against @pure, @nothrow. Nobody could come up with a simple rule as to why 'property' should be an attribute, because it did actually affect the semantics. And (1) means that there are more benefits to making pure and nothrow behave as any other property. If we allow this, then we can just say "for historical reasons, you can leave the @ off @pure and @nothrow". I think that's far easier to justify than the current situation. I'm fully in favour of this.

(In reply to Don from comment #27) > >(In reply to Jonathan M Davis from comment #14) > >> I really think that we've passed the point where it's worth fixing it. > > NO!!!! This attitude is the biggest problem D has. > Please, watch Scott Meyer's talk again. "Most D code is yet to be written". > The future benefits of fixing this kind of crap, are huge. And this one > doesn't even break any existing code. > > Omitting the @ from pure and nothrow was heavily criticized at the time. It > was known to be a stupid decision. Two things have changed since then: > > (1) We now have UDAs. > (2) @property is gone. @property isn't gone. Kenji has been doing work on fixing it up, and in the end, we should end up in the situation where @property makes it so that parens are illegal, and parens are optional for non-@property functions with no arguments. Regardless, I don't see any way that changing which attributes have @ on them and which don't is going to make it consistent unless you put @ on all of them, or you don't put it on any of them. So, either we end up with safe, trusted, system, and property, or we end up with stuff like @public, @const, and @static - which would be hideous IMHO. So, it seems to me that no matter which way we go, we end up with something that's ugly in some way or another, so I see no reason to change it. We'd just be moving the ugliness and inconsistency around. As it is, a very small percentage of the attributes have @ on them, which I think is a good thing. I'd much rather leave @ for UDAs. Regardless, for anything like this to happen, you'd have to convince Walter, and this is exactly the sort of thing he's likely to say no to because it doesn't have any real practical, technical benefit. At best, it just makes it easier for newbies to figure out whether @ goes on the front of an attribute or not, and unless you put @ on _all_ of them, I don't think that it really even does that. So, you're going to have a very hard time convincing him. I expect that he'll see it as useless shuffling around that will break code for no real benefit. - Jonathan M Davis

Closing because this PR was merged: accept @pure @nothrow @return attributes by Walter Bright https://github.com/D-Programming-Language/dmd/pull/4341

wow. so i was right. let's see how long it took for my other suggestions to become blessed.

(In reply to Jonathan M Davis from comment #28) > Regardless, I don't see any way that changing which attributes have @ on > them and which don't is going to make it consistent unless you put @ on all > of them, or you don't put it on any of them. The simplest consistent change would be to have built-in @attributes when they *only affect* functions, not variables. Then we don't need @const or @ref, as they can also affect variables/parameters. We would have @pure, @nothrow, @override, @abstract, @final ('@final class' only affects a class's methods, not variable members). 'return' would not be an attribute, as it can affect parameters. Using this guideline, we only have to change 5 attributes.

Automated migration from keyword syntax to attribute syntax can be done by dfix. Then attribute syntax can be enforced if needed.

(In reply to Sobirari Muhomori from comment #32) > Automated migration from keyword syntax to attribute syntax can be done by > dfix. Then attribute syntax can be enforced if needed. I don't think that that's really the problem. The problem is that no proposal has been given which really makes the attribute names consistent in a way that makes sense to actually change to. We may agree that the status quo is ugly, but how things should be changed is not at all clear. So, we don't even know how we'd want to change the language to fix the attribute situation. And even if dfix makes it easy to change code, breaking code still causes problems. So, while dfix will definitely help reduce the pain when we do decide to make changes to the language which will require changing existing code, it doesn't make the language changes free. The fact that dfix could make it easy to change existing code does not mean that it's okay to make breaking changes without a very good reason behind them.

https://github.com/D-Programming-Language/dmd/pull/4349 The discussion was inconclusive?

(In reply to Sobirari Muhomori from comment #34) > https://github.com/D-Programming-Language/dmd/pull/4349 > The discussion was inconclusive? The change was reverted, though I don't know how conclusive the discussion that resulted was. Walter seemed to want to discuss it primarily so that we could close this as "won't fix" and move on (though I'm not sure that he was entirely against the idea), and Andrei definitely seemed to think that messing around with @ was a waste of time, but I don't think that it was ever definitively said what we'd do about it other than the fact that we'd revert the change until we were sure that we wanted to make it. Certainly, there was no consensus that this change should be made, and if anything, I think that the discussion leaned towards not making it, even aside from what Walter and Andrei thought, but I'd have to reread the thread to be sure of the details at this point. So, I'd say that this is almost certainly a "won't fix," but to be 100% sure, Walter or Andrei would have to say that that was the case. The discussion was here: http://forum.dlang.org/post/[email protected]

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18875 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB