DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 06:31:08 UTC, Johannes Pfau wrote:
> Am Thu, 27 Jul 2017 23:38:33 +0000
> schrieb Nicholas Wilson <iamthewilsonator at hotmail.com>:
>> 
>> It is actually a very simple change, from the end user
>> perspective.
>> * Function attributes that were keyword like, become regular
>> attributes.
>> * They can be applied to modules, acting as a default for
>> applicable symbols in the module.
>> 
>
> I think it also makes sense from a compiler perspective. When 
> these attributes were introduce, we didn't have UDAs yet. Then 
> we introduced UDAs and now UDAs are more full-featured than the 
> original compiler hardcoded attributes:

Indeed all the LDC compiler specific attribute are regular UDAs. 
This also open the way for more parametric attributes and reduces 
the "urgh more attributes" and since they would be symbols we can 
phase the _in_ with `@future`.

> UDAs do not introduce names into the global namespace, UDAs can 
> use fully qualified names, multiple UDAs can be combined or 
> aliased (as commonly done in C for dll export attributes using 
> #defines. We can't do such things in D right now). So I think 
> moving the compiler attributes to UDAs is certainly useful.
>
> But it seems this DIP fails to stress the rationale and 
> confuses people with some implementation detail. I think it's 
> important to show the simple use cases, where object.d auto 
> imports everything and aliases are used so you can use normal 
> @nogc void foo()... syntax. Then maybe show how to group or 
> alias attributes.
>
> -- Johannes

Duly noted.