DIP 1012--Attributes--Preliminary Review Round 1

[Jonathan M Davis via Digitalmars-d]

On Friday, July 28, 2017 01:13:10 Nicholas Wilson via Digitalmars-d wrote:
> IIRC the reason they lack a leading @ is purely historical and
> considered not good but not worth breaking code over. I believe
> this DIP presents an opportunity and reason to make that change.
> Existing code will still work i.e. we can deprecate the old form,
> since both the new and the old are implementation controlled, and
> make it become a positional keyword or the like.

The only reason that _any_ of them have @ on them was to avoid creating a
new keyword. And I for one would hate to see @ on all of them. It's just
trading on inconsistency for another. Should public have @ on it? Should
static have @ on it? What about scope, const, or shared? You're just taking
a subset of the attributes and turning them into enums with @ on them and
leaving some of them as-is. How is that making things more consistent? It's
just shuffling the attributes around and for some reason turns some of them
into enums while leaving others as they are.

IMHO, doing anything to change the current attributes had better have an
_extremely_ good reason, and this DIP does not give that. Yes, being able to
negate attributes would be valuable, but that really doesn't seem to be what
this DIP is about much as that's what it gives as a rationale. Instead, it
seems to be talking about altering attributes in a manner which makes them
way more complicated than they are now.

I also _really_ don't like the idea of having aliases for built-in
attributes. If we had that, instead of looking at a function and seeing
@safe, pure, nothrow, etc., we could end up seing something like
@VibeDefault, and then you'd have to go figure out what on earth that was,
and even after you figured out what it was, it could change later. At least
with what we have now, I can know what I'm looking at.

In addition, it looks like the DIP is talking about what the default
attributes in general are. It's one thing to slap a default set of
attributes at the top of a module and then negate them later in the module
(which we can already do with attributes like public or @safe but can't do
with some of the others like pure or nothrow). It's a different thing
entirely to basically change the default attributes via a compiler switch.
That's just dividing the language. You end up with code that works with one
set of compiler switches but not another and is thus incompatible with other
code - because of a compiler switch. Walter has been against such compiler
flags every time that they've come up, and I am in complete agreement. We've
only used them as transitional flags that are supposed to go away eventually
(like -dip25 or -dip1000). Whether the code is legal or not should not
depend on the compiler flags.

And honestly, showing stuff like @core.attribute.GarbageCollectedness.gc in
the DIP makes it look _really_ bad. Sure, it might make sense from the
standpoint of extensibility, but it's ridiculously long. We already arguably
have too much of an attribute mess on your average non-templated function
signature without stuff like that.

IMHO, if what we're trying to do is to be able to negate attributes, then we
should looking at doing something like @nogc(false) or some other syntax
that is about negation of an existing attribute. This DIP is going off on a
huge tangent from that with no justification as to why it would be worth the
extra complication or the breakage that it would cause. And it looks like a
_lot_ of extra complication in comparison to what we have now.

- Jonathan M Davis