Generating code based on UDA

[Rares Pop via Digitalmars-d-learn]

I think it is a bug.
Executing linked code from a mixin statement should not reduce 
the scope of the mixin, IMHO.

I will file a bug report.

On Saturday, 25 October 2014 at 21:35:44 UTC, Ali Çehreli wrote:
> On 10/25/2014 08:56 AM, Rares Pop wrote:
>
> > Indeed it worked. What is the rationale behind the
> mixin(fullName) ?
>
> __traits(getAttributes) requires a symbol but fullName is a 
> string. Mixing it in as code fulfills the requirement.
>
> > However, in my project the injections function, the @Inject
> UDA struct
> > and some other dependencies are defined in a library
> (libinfuse).
>
> I am afraid it needs to be changed. :-/
>
> > In this format the compiler gives the undefined identifier
> error I was
> > mentioning in my first post.
> > "source/infuse/injector.d-mixin-148(148): Error: undefined
> identifier B"
>
> I found two solutions:
>
> a) Do not define 'attributes' at all and use 
> __traits(getAttributes) directly in the foreach loop:
>
>     foreach (attr; __traits(getAttributes, mixin(fullName))) {
>
> b) Define attributes as a typeof of __traits(getAttributes) and 
> use that in the foreach loop:
>
>     alias attributes = typeof(__traits(getAttributes, 
> mixin(fullName)));
>     foreach (attr; attributes) {
>
> I think what happens in both cases is that the entity that we 
> iterate over maintains its TypeTuple'ness without trying to 
> produce a value out of its members.
>
> > Is this a dmd compiler bug?
>
> I don't know but it is very confusing.
>
> Ali