I dun a DIP, possibly the best DIP ever

[Steven Schveighoffer]

On 4/22/20 8:04 AM, Manu wrote:
> We have a compile time problem, and this is basically the cure.
> Intuitively, people imagine CTFE is expensive (and it kinda is), but 
> really, the reason our compile times are bad is template instantiation.
> 
> This DIP single-handedly fixes compile-time issues in programs I've 
> written by reducing template instantiations by near-100%, in particular, 
> the expensive ones; recursive instantiations, usually implementing some 
> form of static map.
> 
> https://github.com/dlang/DIPs/pull/188
> 
> This is an RFC on a draft, but I'd like to submit it with a reference 
> implementation soon.
> 
> Stefan Koch has helped me with a reference implementation, which has so 
> far gone surprisingly smoothly, and has shown 50x improvement in compile 
> times in some artificial tests.

Yes please! Where is the reference implementation? I want to try some 
things out.

> I expect much greater improvements in situations where recursive 
> template expansion reaches a practical threshold due to quadratic 
> resource consumption used by recursive expansions (junk template 
> instantiations, and explosive symbol name lengths).
> This should also drastically reduce compiler memory consumption in 
> meta-programming heavy applications..

We have a project that I had to completely refactor because the memory 
consumption was so great during compile time, that I ran out of memory 
on a 12GB virtual machine on my 16GB macbook. The refactoring made a 
difference, but now it's back up and I needed to buy a new system with 
32GB of RAM just to build. I understand Weka had similar issues, I 
wonder if anyone on that team can elaborate whether this might help fix 
those problems.

But I want to see if it actually would fix the problems. It's still a 
good change, but I'm not sure it will be the solution to all these.

> In addition to that, it's simple, terse, and reduces program logic 
> indirection via 'utility' template definitions, which I find improves 
> readability substantially.

There were some posts on "how do I do this in D" that used C++ parameter 
pack expansion that just weren't possible or horrible to implement in D.

I wonder if your DIP can solve them? I think it can.

e.g.: https://forum.dlang.org/post/ymlqbjblbjxoitoctevl@forum.dlang.org

I think can be solved just like C++:

int double_int(int val) { return 2 * val; }

T double_int(T val) { return val; }

void double_ints(alias pred, T... args) {
    pred(double_int(args)...);
}

That's awesome.

In my dconf talk last year, I talked about how D's metaprogramming was 
its crown jewel, and we should prioritize anything that makes this more 
usable/possible. This is the kind of stuff I was talking about. Well done!

-Steve