D Language Foundation Monthly Meeting Summary for December 2022

[Adam D Ruppe]

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.