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.