On Saturday, 25 October 2014 at 16:01:29 UTC, Rares Pop wrote:
> I've uploaded the code here:
> https://github.com/fusionbeam/infuse

compiling with ldc2 exhibits the same behaviour.
'Error: undefined identifier B'

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

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

I have found the problem.
It was the nested mixin that was causing the scope degradation (not sure if that is intended behaviour).

The correct way to iterate through members and get their attribute is  like this:

foreach(member; __traits(allMembers,T))
	{		
		enum fullName = format("%s.%s", T.stringof, member);
		pragma(msg, "member: ", fullName);
		foreach(attr; __traits(getAttributes, __traits(getMember, T, member)))
		{
....