custom attribute proposal (yeah, another one)
Steven Schveighoffer
schveiguy at yahoo.com
Fri Apr 6 06:50:45 PDT 2012
On Fri, 06 Apr 2012 09:43:37 -0400, Adam D. Ruppe
<destructionator at gmail.com> wrote:
> On Friday, 6 April 2012 at 13:23:03 UTC, Steven Schveighoffer wrote:
>> 1. Introduce a new compiler-defined attribute @attribute (or @attr or
>> something better, the name isn't important).
>> 2. This attribute can *only* be used on a module-level function.
>
> This is a fine time to disallow built-in attribute identifiers.
>
> safe is not a keyword:
>
> int safe() { return 0; }
> void main() { if(safe) assert(0); }
>
> That's valid code.
>
> But, @safe already has a meaning.
>
> While int safe() is fine, @atttribute int safe() shouldn't
> be.
>
> If it throws an error when it sees that declaration, we're
> in business.
>
> @attribute int safe()
> Error: attribute identifer safe is reserved for the compiler
Good point, I agree.
>> 3. @attribute functions *must* be CTFE-able.
>
> Can this be statically checked? Since CTFE-able-ness
> depends on runtime params and errors, I don't think so.
I thought there were two parts to CTFE:
1. The parameters can be determined at compile-time
2. The function has certain attributes (e.g. all source code available,
does not access globals, etc.)
I really was referring to part 2, which I assumed was statically
determined.
This differs from current CTFE-able functions in that the compiler doesn't
know at declaration whether it's going to be used for CTFE or not.
> I'd say this should not be a strict requirement on
> the declaration. Just let the CTFE fail when you try
> to use it.
If this is the only way to do it, I'm fine with that.
-Steve
More information about the Digitalmars-d
mailing list