DIP60: @nogc attribute

[Rikki Cattermole via Digitalmars-d]

On Sunday, 20 April 2014 at 14:38:47 UTC, Frustrated wrote:
> 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...

Sounds like a neat idea, now for some code examples? Because it
sounds like we would need an entirely different notation
mechanism or something crazy.
Like:

struct MyPureFunction(alias MYFUNC) {
      shared static this() {
           registerFunc!(MYFUNC);
      }

      __annotation() {
          static if (!is(ReturnType!MYFUNC == void)) {
              return Tuple!(__annotation(pure),
__annotation(property));
          } else {
              return Tuple!(__anotation(pure));
          }
      }
}

@MyPureFunction
string mypurefunc() {
     return "hi";
}

pragma(msg, mypurefunc);

I added the constructor in there because being able to run code
dependent on it would enable registering of certain types (useful
for e.g. Cmsed so users don't have to).
This would add a new keyword (__annotation) in the same style as
__traits.
__annotation function would be called post constructor meaning
you could negate what you would normally return.
Perhaps another function !__annotation to remove current ones.

Not quite sure how this would relate to @nogc but.. Maybe it
means we can fine tune it per attribute/compiler or something.

But hey just my take.