DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

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).