https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #11 from bearophile_hugs@eml.cc ---
(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.)

--

https://issues.dlang.org/show_bug.cgi?id=13388

Trey Brisbane <tbrisbane@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tbrisbane@gmail.com

--- Comment #12 from Trey Brisbane <tbrisbane@gmail.com> ---
Then what is your alternative proposal?

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #13 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #14 from Jonathan M Davis <jmdavisProg@gmx.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #15 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(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?!" ;-)

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #17 from Jonathan M Davis <jmdavisProg@gmx.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #16 from Trey Brisbane <tbrisbane@gmail.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #18 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
seems that it's time to fork into "D refurbished" project. ;-) no, really, it's only a half-joke…

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #19 from Trey Brisbane <tbrisbane@gmail.com> ---
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"?

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #20 from Jonathan M Davis <jmdavisProg@gmx.com> ---
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.

--