custom attribute proposal (yeah, another one)

[Steven Schveighoffer]

On Fri, 06 Apr 2012 18:40:29 -0400, Piotr Szturmaj <bncrbme at jadamspam.pl>  
wrote:

> Steven Schveighoffer wrote:
>>
>>
>> Unused function do not make it into the EXE.
>
> Are unused structs compiled into EXE?

Their TypeInfo_Struct is.  If they are compiled in their own module, then  
I think it's possible the linker will leave the whole object out.

>> foreach(name, value; __traits(getAttributes, symbol)) {...}
>>
>> hereby added to the proposal.
>
> Ok, but how do you filter that and pass the result to another template?  
> It should be easy if __traits(getAttributes, symbol) would return an  
> expression tuple, which is what I'd like to see.

It has to be a tuple, since the type of value may change on each  
iteration.  It likely must be a tuple of name-value tuples.

>> No, it doesn't generate more typeinfo that must go into the EXE. When
>> the EXE is built, all associated bloat should disappear, it's only
>> needed during compilation.
>
> Those types are only needed during compilation too. However, I don't  
> know if they're always included into binary or only when they're used.

I think they are.  I don't know if it's required though.  I don't know  
enough about the link-time optimizations available to see if they can be  
weeded out if unused.

>>
>> I think you are missing how the metadata is stored as key-value pairs,
>> with the key being the name of the function that was used.
>
> Ok, but it needs more work in the compiler, comparing to identifier  
> search and remembering expression tuple of a symbol.

The compiler can "build" a struct if it wants to, it reduces to the  
equivalent problem.

> Also, I just found a major drawback of this approach: consider  
> parameterless attributes like @NotNull. What would you return from  
> function named NotNull()?

void?  There is no need to store a type, it's just "is NotNull valid or  
not?".  Note that this is somewhat of a red herring, a NotNull attribute  
cannot implement what it purports to.

>>> This is how it's done in C# by the way.
>>
>> Yes I know. I don't think we need to limit ourselves this way, C# does
>> not have the compile-time power that D does.
>
> I didn't state that we shouldn't use compile-time :)

My point was, maybe C# took this route specifically because their lack of  
compile-time facilities didn't allow them a better solution like mine ;)

-Steve