DIP60: @nogc attribute

[Frustrated via Digitalmars-d]

On Sunday, 20 April 2014 at 15:04:28 UTC, Rikki Cattermole wrote:
> 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.

The way I see it is that attributes, in general, are simply meta 
tags applied to things. Just like tags used in audio files.  You 
apply tags, do things with them. You can sort them based on tag, 
only play certain song with certain tags, etc...

Hence, the compiler does not to be coded for specific attributes 
because attributes, in and of themselves do not need code at the 
compiler level to handle them except for possibly optimizations. 
In any case, there should then be a common base for 
attributes(built in or user defined) that generalizes what they 
are now which would also make them more powerful with a little 
work.

As far as @nogc goes, I think it's probably one of the more 
simpler tags in that it it only uses inheritance and logical and 
composition. i.e., if all sub-attribute uses are @nogc then the 
the attribute use becomes @nogc.

E.g., Q uses X, Y, Z which each have attributes x, y, z

Then Q's attribute q = (x == y == z == @nogc) ? @nogc : @gc

[To start off we could say Q's attribute q = x:y:z, a compound 
attribute... and use a "grammar" to simplify q if possible. If 
q's simplified compound attribute exists in the defined 
attributes then processing continues until a atomic attribute is 
found... of course one has to be careful with ambiguity but 
probably won't ever be much of a problem]

Simple expressions and statements can also have implicitly 
defined attributes.

e.g., all of D is, by default @nogc except slicing, new, etc.. 
The GC module then introduces the @gc attribute on some of it's 
functions(not that it really matters cause usually you don't use 
the gc directly but through the core features of D(slicing, new, 
etc...).

If @nogc is defined as above then everything should just *work*. 
The compiler will form compound attributes and simplify them and 
@nogc will propagate. You would rarely ever have to explicitly 
use @nogc or @gc.

Same thing would happen with @pure, @safe, etc... Using the rules 
and possible some deduction the compiler could cute out most of 
the work.

e.g., @pure could be automatically deduced in almost all 
cases(99% of use cases) by marking everything that is no an 
assignment in D as pure. Assignments may or may not be pure 
depending on if they modify parent scope. The compiler determines 
if they do, and if they do then it marks that assignment 
@impure... then uses the same rule for combining all the 
attributes as @nogc.

If the compound attribute can't be reduced. e.g., some 
assignments in D can't be determined as pure or not by D, then 
the pureness is unknown which results in a compound attribute 
that can't be reduced... and hence the user must explicitly mark. 
(e.g., using a pointer assignment which can't guarantee pureness 
unless, maybe, static analysis is used to try and figure it out.

So, in D, some assignments are pure, some are impure, some are 
not provably pure and some are not provably impure. In the case 
of not probably pure/impure one might allow the user force the 
attribute to be one or the other so the compound attribute can be 
resolved. If that is not enough the user could tell the compiler 
to assume the compound attribute resolves to something.

Anyways, really feels like there is some simple mathematical 
structure going on here but I can't quite put my finger on it. We 
have a set of attributes, a set of operators on the set of 
attributes(probably just need symmetric binary operators but 
would be nice to be able to handle the more general case), and 
some "code" to do things with them so user defined attributes are 
more useful.


For example, suppose we have a complex program with two 
functions. Depending on something one function may or may not be 
pure. But lets suppose there is an external reason why the other 
function must always have the same pureness as the first 
function. This seems like a difficult problem because it depends 
on context.

If we have CT reflection of attributes and the ability to define 
attributes in cool ways then

void foo() { } // pure
void bar() @@forceSame(foo, @#pureness)
{ }


where @@forceSame is an attribute meta function that takes a 
symbol and a attribute group, which is the group of related 
attributes, in this case @#pureness = {@pure, @impure}, and 
forces bar to have the same attribute as foo that is within that 
group.

D being as cool as it is, we could even execute user defined code:

void foo() { } // pureness unknown
void bar() @@execute({ if (foo:attributes.is(@pure)) @@set(bar, 
@disable)}
{ }


(just pseudo code so don't get your panties in a wad, but should 
be obvious, if foo is pure then bar is disabled, else it is 
enabled)

Of course one can take it as far as one wants... The point is, 
that we have attributes but no underlying common system which to 
easily build on. Seems like every attribute added to D requires 
re-implementing the wheel more or less.

If such a system was already in D, there would not be any 
discussion about @nogc except possibly should it become a built 
in attribute which the compiler could use for optimization 
purposes.