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