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.NamesWould 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.
