DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips 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
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> My primary points
>
> * Don't formally deprecate the keywords, there is not enough 
> justification to ever remove them.

Indeed the only reason for removing them would be to remove code 
from the compiler. They do no harm at all.

> * Remove the whole program defaults, I'm ok with it being 
> changed in a re-implementation of the runtime (like the 
> embedded example), we just don't need the extra confusion 
> within user code.

The program defaults are there to make @safe by default a thing, 
and betterC by default a thing, which are covered in the _three 
Primary points_ of the semesters Vision document[1]. These would 
not normally be set (i.e. opt in).

> * Specifying inferred needs to be within druntime only, and 
> thus may not need to exist.

I think there is usefulness in having it, particularly as the 
meta-default (defaultAttributeSet). Walter has ben pushing for 
some time to infer attributes by default. This would provide a 
directive for the compiler to do so. Please elaborate.

> * I'm concerned user defined attributes could define a 
> "defaults" for functions.

you mean user UDAs (if not please explain)? the default 
application of UDA is for core attributes only.

>
> I think the updated document needs some additional rework, here 
> are some examples:
>
> # Rational
>
> A number of issues with the existing functional attribute 
> system have come up through the years.
>
> * Certain attributes don't have a name, e.g. All functions 
> ''throws'' but this is not an existing attribute.
> * The default attributes were not correctly chosen, e.g. all 
> class methods should be ''final'' unless specified otherwise, 
> and because of the first point declaring 'final:' at the top of 
> the class cannot be undone.
> * AliasSeq is provided to manage Attributes, but it doesn't 
> handle built in attributes (I could be wrong but is what I'm 
> getting from the document even though it isn't explicitly 
> stated)
> * ...
>
> # Description
>
> Function existing attributes and their unnamed counterpart will 
> exist as an enum within core.attributes. This module will be 
> implicitly imported to provide the symbols without explicit 
> import or breaking existing code. The compiler will recognize 
> the non-@ based attributes as the corresponding core.attribute.
>
> ...
>
> ## Implementation Details
>
> ----------
> module core.attribute;
>
> enum Protection {
> system,
> safe,
> trusted,
> }
>
> alias safe = Protection.safe;
> ...
> -----------
>
> The compiler will default functions to the first value of the 
> enum [for my example].

( That would provide a pessimistic default and debates the 
ability for the compiler to infer)
>
> [So on and so forth]

Thanks for your suggestions.

[1]: https://wiki.dlang.org/Vision/2017H2