Overloads not returning appropriate info. [Field reflunkory]

Adam D. Ruppe destructionator at gmail.com
Wed Apr 10 02:19:42 UTC 2019


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.

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)

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.


More information about the Digitalmars-d-learn mailing list