On Sat, 21 Jun 2014 17:54:33 +0000 Peter Alexander via Digitalmars-d <[email protected]> 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
