On Fri, 16 Mar 2012 14:33:37 -0400, Adam D. Ruppe
<destructiona...@gmail.com> wrote:
On Friday, 16 March 2012 at 18:07:18 UTC, Steven Schveighoffer wrote:
Quote from TDPL (section 5.9.1 on page 156):
Huh. There's nothing I can see in the compiler that even
hints at this. The @ thing is just another storage class
as far as it's concerned right now.
Right, the user-defined portion is not implemented.
Nor do I see a huge number of library or user-defined ones springing up.
Yeah.
I still really like my expression idea though, but
thinking about your strategy, we could say:
When you see @, if it is a compiler word after it,
parse it that way. Otherwise, try to get a function
call out of it.
The way I'd like to see it work (and not being a compiler writer, I have
no idea if/how this would work) is:
When you see @, call a CTFE function with that name.
The compiler defines intrinsic functions @property, @disable, etc. which
return intrinsic data types that get appended to the attribute list. Then
the compiler recognizes those data types in the attribute list when
deciding how things should be compiled.
This might not be feasible given the current implementation, or how
compilers are designed, I have no idea.
The return value is appended to the declaration's
attribute expression list (so the end result is the same
as I was thinking.)
Yes. And I'd like to see the other intrinsic attributes appended (and
queryable) as well.
What we also may need in the @annotation declaration is an alias of the
thing being compiled (again, don't know how feasible this is)
for example:
@annotation property(alias sym)() { static assert(is(sym == function));
return INTRINSIC.isProperty;}
Maybe that's going too far :)
-Steve
