On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
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.
Fair enough, but its always slightly annoyed me that `pure` and
`nothrow` don't have leading '@'s.
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.
This DIP is in the process of being amended to explicitly exclude
linkage, storage class & visibility attributes. That Subset are
function attributes under the 'Encompassed' and 'Optionally
encompassed' subsections of "Attributes & attribute-like compiler
behaviour encompassed in this DIP".
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.
Its turning keyword-like compiler magic attributes into regular
compiler attributes.
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.
That is a feature.
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.
I dont mean to be snide but either
1) ignore them, i see AliasSeq of attributes more useful for end
users, i.e. application developers, or
2) use an IDE.
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.
That was an Illustrative mistake and I regret the confusion it
has caused. I should have used `@gc` with `@gc` being an alias
for @core.attribute.GarbageCollectedness.gc.
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.
This dip is intended to reduce the amount of attribute spam by
enabling defaults.
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.
The DIP is more than that, the benefit of being regular
attributes (manipulation) and the ability to have configurable
defaults,
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.
This would cause _very_ little if any, non-deprecatable breakage.
And it looks like a _lot_ of extra complication in comparison
to what we have now.
The keyword-like attributes become regular attributes. I fail to
see how that makes them any more complicated, IMO it makes them
_less_ complicated (I am revising the DIP to remove the module
related stuff and have a last applied wins for multiple
attributes).
