DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 00:32:33 UTC, Mike wrote:
> On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
>> DIP 1012 is titled "Attributes".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
>
> Terminology:
> I was confused by the term "attribute group". Although the term 
> is defined in the DIP, it implies a combination of attributes 
> rather than a mutually exclusive attribute category.  Still 
> having trouble understanding the DIP in detail due to this.

If you have a better name, please do tell.

>
> Rationale:
> The rationale is weak, but reading the "Description" appears 
> that there's more to this DIP than what the rationale 
> describes.  I suggest an enumerated list of problem/solution 
> pairs that this DIP addresses.

Good idea.

> Description:
>> It is also possible for the end user to directly control 
>> core.attribute.defaultAttributeSet by editing DRuntime 
>> directly.
>
> Does this mean we can create an @safe-by-default or 
> @final-by-default runtime?  if so, cool!, but that should be 
> spelled out in more detail in the rationale.

Hmm, the runtime may have to be a special case for attribute 
inference,
I suspect that it does a whole bunch of things that are unsafe 
and the GC itself being @nogc is a bit weird (though I suppose 
you just link it out anyway). Not to mention global state being 
impure.

>> @core.attribute.GarbageCollectedness.inferred
> That is way too verbose.  Is that just an illustration or is 
> that really what we would need to be typing out?
>

Illustration, I expect that one will be able to go

@infer!(GarbageCollectedness, FunctionSafety)
or
@infer!(nogc,safe)

to both mean the same thing (or a combination of the above), but 
infer will be the default anyway I suspect. where `infer` just 
selects the inferred value of the enum and build an AliasSeq from 
them

> Breaking changes / deprecation process:
> It would be nice to get some decision early from the leadership 
> if they would be willing to deprecate the no-leading-@ on 
> attributes that are used with such proliferation in D code, as 
> otherwise there will be a lot of time reviewing and debating 
> this for nothing.  Sounds like a risky gamble.
>
> Mike

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.