On Wednesday, January 28, 2015 14:41:08 Dicebot via Digitalmars-d wrote: > On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote: > > On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote: > >> But in this case I see no improvement that could justify it. > > > > Fixes problems people have with inconsistent attribute syntax, > > see discussion at https://issues.dlang.org/show_bug.cgi?id=13388 > > Yes, but as it has been already mentioned in this thread new > system is as much inconsistent - it simply has moved 3 of > attributes from one "camp" to another. If idea was to separate > attributes that affect mangling/type then we still have > protection attributes. And with no plans to deprecate old syntax > even more inconsistency had been introduced. Same goes for > possible introduction of new attributes - if syntax for those and > UDA is identical, it can break code same as introducing new > keywords. I don't see any _vision_ behind the change, just moving > bits around. > > It is not well-thought.
Exactly. It's not like this is simply a discussion of whether a change which makes the language more consistent is worth the breaking changes that it causes. Rather, The change doesn't actually fix anything. It just moves stuff around. If more things were moved around, then maybe they'd become more consistent and would actually help the situation, but that's not what's happened. A few were attributes moved from one camp to the other with no real plan, and because it took attributes from the smaller camp and put them in the larger one, it's actually decreasing consistency and making the situation worse rather than improving it. If we're going to shuffle attributes around, we need to do it in a way that actually follows a plan and makes the language more consistent. That's not what's happening here. We either need to come up with a complete plan for shuffling attributes around in a way that will actually make them fully consistent, or we need to revert these changes and stick with the status quo. Anything else just shuffles things around without fixing the problem, and it increases confusion in the process. And honestly, after several discussions on this in the past, I don't think that it's actually possible to make the attributes fully consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expects (e.g. @ on a whole bunch of keywords like private or final that other languages don't put @ on and which none of the current D literature or code out there puts @ on). I think that this is a case of folks trying to shuffle things around to fix something that just can't be fixed. At best, it'll just end up being ugly in a different way. - Jonathan M Davis
