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.
