On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
As far as he understood, the only time `@property` has an
effect is when you take the address of a function it annotates.
It is when you do typeof(thing.prop), not &thing.prop.
Walter said that `__traits` is meant to be ugly.
We should revisit this decision. I don't think it ever made
sense, and especially now with the benefit of hindsight it looks
like a clear unforced error.
Robert said that doesn't solve his problem with compile times.
He has a project that doesn't use much of Phobos, but compile
times still suffer. The compiler is slow.
I'd like to know more about this project....
He had previously dug into `hasUDA` and it was scary how many
recursive expansions he found.
We should also revisit the abstractions here. The more I use
these the more I've been landing on something like what Steve
described in the dconf online. It is faster to compile, more
flexible with runtime reuse, and just generally easier to
document and use.
Then we can just let hasUDA and friends die.
That goes to the idea of caching or pre-compiling the template
so that
Please note that the compiler does cache templates right now, and
it takes gigs of memory. A lot of work would have to be done to
make this good since work not done is still better than work
unnecessarily done... and if it is cached too aggressively you
just run out of memory.
If the end result is simple, we ought to be able to discard
intermediate results, but the current implementation doesn't even
allow this!
We don't have [...] `std.html` [...] We just need someone to
write them.
Yes, if only some did that 13 years ago and has been continuously
maintaining it ever since. If only ~someone~ wrote that.
Something was causing the struct configuration to take over 10
minutes to compile.
If you did any string replacements that'd slaughter your
performance, the ctfe engine is *extremely* bad at this.
In my arsd.jni, I had a string like:
enum code = q{
PRETEND_MACRO void foo() { implementation; }
};
mixin(code.replace("PRETEND_MACRO", ""));
mixin(code.replace("PRETEND_MACRO", "static"));
Those two simple lines added 30 seconds to the compile time! Just
copy/pasting it and replacing the pretend macro ahead of time cut
95% of the build time off. It was astonishing.
You can optimize some of these with mutable buffers, avoid the
concat operator in ctfe even if it means two passes through the
data. This helps a lot.
But also just using template mixins tends to work well when you
know the proper techniques.
