Overloads not returning appropriate info. [Field reflunkory]

[Alex]

On Wednesday, 10 April 2019 at 02:19:42 UTC, Adam D. Ruppe wrote:
> On Tuesday, 9 April 2019 at 20:45:18 UTC, Alex wrote:
>> On Tuesday, 9 April 2019 at 18:33:21 UTC, Seb wrote:
>>> Have you considered writing a DIP?
>>
>> No, because I expect it won't even be considered.
>
> You won't pass review if you don't show knowledge of the 
> existing language, but there's a lot of people who are 
> interested in a few changes.
>
> A few years ago, there was a proposal for a magical `meta` 
> namespace that would call into the compiler for syntax sugar on 
> CT reflection. The old idea was to replace `__traits(X, args)` 
> with `meta.X(args)` - pure syntax change - but you could 
> perhaps revive and expand that as the entry point to your new 
> idea and get some people on board.

Yeah, but that isn't really effective, virtually identical. I am 
talking about one level higher abstraction. I mean, it's all the 
same but I'd like things to be sorta based in oop and ranges(UFCS 
like stuff). I haven't though about it enough to know how it 
would work out but I imagine things could be done very nicely. 
E.g., some accessors get information and some process that 
information and one can combine and match as needed. X.Type.name, 
X.Members.Select!"foo".Memebers.Select!"bar"(assuming foo is an 
aggregate), etc.

Range functionality could even be used to process arrays(I guess 
the return of the traits would need to be ranges).

> I'm skeptical of any reflection library, but compiler changes 
> might be able to change that. The status quo for D's reflection 
> libraries are:
>
> 1) weird bugs and/or omissions since the language does not let 
> you express all the function parameter details as return values 
> or local variables.
>
> 2) slow compile times (you said your thing was 10 seconds! 
> that's utterly unacceptable)
>

It actually is not to bad. I haven't done much testing but at 
least repeatedly calling the Reflect on the same base type added 
little overhead(it wasn't scaling linearly with the number of 
calls). So maybe it has a chance. Still will never be as 
efficient as doing it internally though.

> 3) not actually significantly easier to use than language 
> built-ins (if they are actually easier to use at all!)
>
>
> So any library without compiler changes is, as of today, I 
> believe *impossible* to get right, and getting as close as you 
> can is horribly slow. So, your DIP would necessarily include 
> language+compiler changes.
>
> And the compiler is *already* (almost) fully capable, so 
> changing that needs to show that the change is worth it. Maybe 
> you can do that, even little cosmetic things can indeed be a 
> win, but to write a convincing case here, you'll need to 
> compare and contrast various cases.

I'd definitely rather see this in the compiler. I just no zero 
about Dmd's design and the specifics. It's not something I'm 
capable of doing without a significant investment that I'm not 
willing to do(only if I could add the design on top without 
having to "learn" everything about the compiler).


My goal was to sort of bridge the gap of the ideal solution and 
what we have. Something I could use personally to solve most of 
the frustrations I have but I wasn't thinking of trying to make 
it in to something ideal.