DIP60: @nogc attribute

[Frustrated via Digitalmars-d]

On Wednesday, 16 April 2014 at 02:14:18 UTC, Walter Bright wrote:
> On 4/15/2014 6:57 PM, Mike wrote:
>> I suspect some of the motivation for this is to give customers 
>> "faster horses".
>> I would be surprised if a @nogc attribute increased D's 
>> appeal, and I think
>> efforts would be better allocated to some form of the above.
>
> Asking for @nogc comes up *constantly*.

How bout this!

Why not allow one to define their own attributes from a 
generalized subset and then define a few standard ones like @nogc.

i.e., instead of having to define specific attributes every few 
years to satisfy some new thing, why not just abstract the 
process.

Attributes, I believe, are essentially relationships between 
parts of code?

If so, then one simply has to implement some generic way to 
specify the attributes and properties of the relationship to the 
compiler. Then anyone would have the tools to define and use 
these attributes as they wish. (in fact, I think it would just 
involve enhancing the current attribute support, probably just 
need to rewrite it all so that the same code is used for built in 
attributes(@safe, @pure, etc...) and user define attributes.


So, we just need to define the attribute name and the properties 
it has such as:

Assume Y uses X in some way(function call) and X has an attribute 
A defined on it:

Inheritance - Y inherits attribute A.

Exclusion - If Y has attribute B and B is mutually excluded from 
A then error

Composition - If Y also uses Z and Z has attribute B then Y has 
the compound attribute (A:B). Compound attributes can be 
rewritten to other attributes using a grammar/reduction scheme. 
Some compositions can be invalid. E.g., @nogc and @gc, @pure and 
@notpure, etc...

Duality - If an attribute A is not specified for a block of code 
then it's inverse attribute is implicitly specified always. e.g., 
@gc and @!gc = @nogc are duals and one or the other always is 
specified, even if implicit.

etc... [Note, I'm not saying all attributes have these 
properties, just that these the possible properties they can have]



By coming up with a general system(I'm sure there is some 
mathematical structure that describes attributes) it would be 
very easy to add attributes in the future and there would be a 
consistent code backing for them. It would also be easier for CT 
reflection on attributes.


Anyways, just a thought, sounds easy in theory...