DIP64: Attribute Cleanup

[H. S. Teoh via Digitalmars-d]

On Sat, Jun 21, 2014 at 12:41:26PM -0700, Jonathan M Davis via Digitalmars-d wrote:
[...]
> 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.
[...]

Maybe we should be considering *removing* @ from @safe and @nogc? But I
don't see that flying either, since it can well conflict with existing
user-defined identifiers.

OTOH, I think there is some distinction between, say, pure and public,
because pure is something that can be inferred, and it involves
restricting the set of allowed code in the body of the function
(likewise with nothrow, @safe, @nogc), whereas public merely affects
external access to the function. The latter can't be inferred
automatically (and it doesn't make sense to do so), but the former can.
Furthermore, in the former case, it makes sense for a function's
attributes to depend on its arguments -- e.g., opApply can be pure if
the delegate argument is pure, but it doesn't make sense for opApply to
be public/protected/private just because its argument is.

So there's at least some amount of rationale for treating the two
categories of attributes differently.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry