accept @pure @nothrow @return attributes

[Jonathan M Davis via Digitalmars-d]

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