I give up! I tried to create a reflection library but D's traits are just too screwed up!

[Alex]

On Wednesday, 3 April 2019 at 09:24:23 UTC, Atila Neves wrote:
> On Wednesday, 3 April 2019 at 07:22:10 UTC, Alex wrote:
>
>> But D's type system is too screwed up. Fields and members are 
>> not treated as types in and have themselves so
>
> I don't know what this means.

One cannot pass a field type around like one can a class. Using 
Fields and FieldsNameTuple does not create a type. This then 
requires one trying to exact the type info by hacking which then 
requires all kinds of tricks that never ultimately succeed. If 
they do work in one aspect they completely breakdown in another.

The BaseReflection class should is supppose to encapsulate 
getting the name, id, module, etc of any base reflected type. 
Works fine for aggregates...
The moment you try to use it on a field it fails because fields 
don't have a type. Specializing for fields then sends one off in 
a different direction and it fail fails.

I posted all the code for you. It should not be difficult to 
understand and get working with your knowledge about D's meta 
system.

Simply put the different code snippets in their appropriate 
modules and run. It should work. Note the output and the fields 
and methods section.

Now try to get the code to fill in the appropriate data for them. 
That is all. It should be an easy task, right? (I have 
specialized for the fields by hacking but the private bug stops 
it from being general enough)


>
>> 1. Building a compact code base is impossible.
>
> I beg to differ:
>
> https://github.com/kaleidicassociates/autowrap/blob/master/reflection/source/autowrap/reflection.d

You can beg all you want, I'm not talking about specific 
examples, I'm talking about in general. Meaning that in general 
when one is trying to create certain domains of meta programming 
they run in to a brick wall like I have.

>
>> 2. The type system sometimes requires using alias and 
>> sometimes a type yet there is no way to unify the two to 
>> reduce code bloat and everything must be duplicated.
>
> void foo(T...)() if(T.length == 1) { /* ... */ }

Doesn't work well, I have used that. Doesn't always work.

>
>>3. The Type's do not carry their moodules and
>> import automatically so the symbols can be used.
>
> import std.traits: moduleName;
> mixin(`import `, moduleName!thingie, `;`);

Um, that is not safe.

>> This requires getting the module and importanting things. 
>> Further more certain _traits want a this object to work for 
>> fields
>
> Use T.init when that's the case.

Doesn't always work. I have done it.

>
>> and others don't but none of the methods seem sensical. 4. If 
>> a symbol is private CT __traits fails..., again non-sensical.
>
> See my reply to your other post.

I posted all my code, have fun trying to get it to work... I have 
used all your "solutions" in the process and none of them 
ultimate worked. I did this before you posted.

These solutions do not work in all cases while other times they.

Since you are a master at it, it should take you no time to fix 
up the code above. Just need to get the members or fields 
properly You can