• Random D user (42/42) Jun 11 2016 Any good ideas how to do that?
• Basile B. (3/13) Jun 11 2016 It will compile if you define the option informational warnings
• Random D user (12/27) Jun 12 2016 Yes, ignoring deprecations gets me forward (basically the same as

Random D user <no email.com> writes:

Any good ideas how to do that?

I couldn't figure it out in a short amount of time, but I expect 
that it's possible. I'm probably missing something obvious here. 
Probably because D's reflection/meta programming facilities are a 
bit all over the place (and unnecessarily convoluted IMO).
Also I'm not super familiar with every compile-time feature, 
which is why I want to learn and some meta functions/templates 
myself.

In my usecase I want to extract structs with UDAs from a module, 
which also imports bunch of stuff. Now __traits(allMembers) gives 
me the list of things (in strings) that the module contains. This 
includes module imports and when I do something like this (in 
pseudo D):

template
{
   foreach(name ; __traits(allMembers, MODULE) )
     foreach(attr_name ; __traits(getAttributes, 
__traits(getMember, MODULE, name)))
       whatever logic...
}

I get "Deprecation: foo.bar is not visible from module baz" with 
2.071+ compiler (i.e. import symbol lookup rules changed) where 
foo.bar is an import in MODULE and baz is the module where the 
template for code above is located. And I'm calling the template 
from yet another module qux. This used to work with previous 
versions (modules were just skipped).
The trouble begins when an import module is passed to 
__traits(getMember). (however I can do __traits(hasMember) which 
is a bit weird, since I'd assume same visibility rules would 
apply).

Here's a pseudo example:

mymodule.d:
import foo.bar;
 uda
struct mystruct

baz.d
template get_uda_structs

qux.d
import mymodule.d
import baz.d
auto structs = get_uda_structs(mymodule, uda); // Won't compile: 
"Deprecation: foo.bar is not visible from module baz"

Basile B. <b2.temp gmx.com> writes:

On Saturday, 11 June 2016 at 19:45:56 UTC, Random D user wrote:
 Any good ideas how to do that?

 I couldn't figure it out in a short amount of time, but I 
 expect that it's possible. I'm probably missing something 
 obvious here. Probably because D's reflection/meta programming 
 facilities are a bit all over the place (and unnecessarily 
 convoluted IMO).
 Also I'm not super familiar with every compile-time feature, 
 which is why I want to learn and some meta functions/templates 
 myself.

 [...]

It will compile if you define the option informational warnings 
(-wi).

Random D user <no email.com> writes:

On Saturday, 11 June 2016 at 20:30:47 UTC, Basile B. wrote:
 On Saturday, 11 June 2016 at 19:45:56 UTC, Random D user wrote:
 Any good ideas how to do that?

 I couldn't figure it out in a short amount of time, but I 
 expect that it's possible. I'm probably missing something 
 obvious here. Probably because D's reflection/meta programming 
 facilities are a bit all over the place (and unnecessarily 
 convoluted IMO).
 Also I'm not super familiar with every compile-time feature, 
 which is why I want to learn and some meta functions/templates 
 myself.

 [...]

 It will compile if you define the option informational warnings 
 (-wi).

Yes, ignoring deprecations gets me forward (basically the same as 
dropping back to previous compiler version), but I'd rather 
figure out/know a proper solution.

I suppose I could wrap those structs (with UDA) into a another 
named struct or empty template to split them into a separate 
"namespace" from the import modules.
I guess that wouldn't be as bad since all the structs are similar 
which means their names are similar. So basically, NameType would 
become Type.Name. Hmm...

Anyway, that workaround seems a bit silly, so I'm hoping to find 
a proper, generic and robust solution without any gimmicks.