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.
