Overloads not returning appropriate info. [Field reflunkory]

[Alex]

On Tuesday, 9 April 2019 at 18:33:21 UTC, Seb wrote:
> On Tuesday, 9 April 2019 at 16:30:53 UTC, Alex wrote:
>> On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote:
>>>[...]
>> I didn't say the language. The point with the language is that 
>> it could have built in semantics to do reflection in a inform 
>> way(__traits is somewhat uniform but messy and then one has 
>> std.traits which then makes it not uniform).
>>
>> [...]
>
> Have you considered writing a DIP?

No, because I expect it won't even be considered. The typical 
responses I have seen to this sort of thing is that "we already 
have it". Hence why I decided to write my own lib, and then had a 
few issues.

Andre did look in to some of the ideas and said he would pass it 
off to some GSOC students to look in to making it better, so 
maybe something will come out of that.

I believe that basically the compiler simply needs to present a 
better interface in to reflection. This should have been done 
from the get go but I guess __traits has been patched together 
over time as as things were needed.

Essentially the compiler would need to do what I have done and 
wrap __traits and std.traits in to a more uniform interface. It 
would add an extra layer of indirection though since the wrapper 
needs then to stay consistent with any traits changes.


My library works well but is incomplete and has some bugs to due 
bugs in traits. It is, though, rather slow and I haven't worked 
on fixing it. (actually it doesn't seem to add too much overhead 
after the first call but I imagine that is due to the template 
being instantiated already in the module, might multiply for each 
new module it is used in)


What I'm thinking is that maybe it is better to have some range 
like semantics used for reflection. I have thought about it much 
but I got the idea earlier.

Type.Reflect.Accessor.Accessor.Selector.Selector.Accessor...

The idea is that one can access stuff from the type and then use 
certain keywords to select and filter and then access more.

I say it is range like but I'm not sure if ranges would work or 
not or if it would just be dispatching.

E.g.,

MyClass.Reflect.TemplateParameters.Select!int.Names

Would get the template parameters of MyClass, then select only 
those with int and then get the names of those parameters.

(this could work in general for runtime too)

MyClass.SomeArray.Select("x.value == 4").name;

which is why I say it is sorta like ranges(which I'm thinking 
more of piping).


I just haven't thought about it much and there doesn't seem to be 
much interest in going this route... I think it would be a great 
addition to D but others seem to not care or are more interested 
in arguing to relatively insignificant issues.