Overloads not returning appropriate info. [Field reflunkory]

[Adam D. Ruppe]

On Sunday, 7 April 2019 at 17:42:58 UTC, Alex wrote:
> That is blatantly wrong. The code works EXACTLY the same way 
> with and without using stringof.

In some cases, yeah. In the general case, no.

Your import hack* is only there because of stringof. Using the 
local symbol, there is no need to import the module. This means 
you avoid name conflicts with local symbols (like I pointed out 
in the linked post) and it has the potential to avoid protection 
violation errors, since you are no longer getting the symbol from 
your module; it is gotten somewhere else, ideally from its own 
module, and passed to you, which is allowed even for private or 
hidden symbols.

It also just makes the code a lot simpler, so there's no more 
need to jump through hoops to debug it.

* 
https://github.com/IncipientDesigns/Dlang_Reflect/blob/master/mReflect.d#L61

> I have removed all T.stringof's in the code and I still get the 
> exact same errors.

That's the first step. Then, you clean up the hacks that were 
introduced to work around stringof's problems and get a better 
design that actually works, like passing private members from one 
module to another via alias parameters.

> one could just open the source if there was anything to "hide"

That's not necessarily true, it is possible to have code exclude 
private members. In fact, it is often considered good practice to 
do that for library releases for encapsulation!

> Protection is a runtime thing(except for CTFE).

Protection *only* exists at compile time - at runtime, there's 
zero checks. There's nothing preventing you from passing a 
pointer to a private member, for example.

This is why __traits(getMember) fails the same as T.name, but it 
is also the reason why there's hope to cheat here, at least once 
you get a correct foundation laid, by using mixin templates 
and/or passing aliases cross module.

(interestingly, .tupleof does let you bypass privacy protections, 
but only for aggregate members, not for methods.)