I dun a DIP, possibly the best DIP ever

[Steven Schveighoffer]

On 4/22/20 9:35 AM, Manu wrote:
> On Wed, Apr 22, 2020 at 11:20 PM Steven Schveighoffer via Digitalmars-d 
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
> 
>     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.
> 
> 
> The link is in the DIP.

Oops, it's at the top, I missed that. Thanks.

> Most tests we've done are working, except template instantiation 
> expansion is not yet implemented: ie, Thing!(Tuple, x, y)...
> That's got a lot of implementation baggage attached to it in DMD.

Ugh, I think I won't be able to test then, most of this stuff works with 
lists of types, not values.

And come to think of it, staticMap works, but I need Filter as well. I 
suppose it can help a bit, but I still am going to have tons of 
"temporary" templates that are going to clog up the memory.

Stefan, where's that implementation of first class types for CTFE-only 
functions you promised? ;)

> 
> I expect you won't be able to run practical tests on real code yet 
> without TemplateInstance expansion.
> The problem is that existing code is factored exclusively into 
> template instantiations, so a trivial experiment will apply to existing 
> code in that form.

The trivial experiment to test is to take a list of types with possible 
duplicates and remove all duplicates. It doesn't have to be in any order.

I'm hoping something like this might work:

template NewFilter(pred, T...)
{
    template process(U) {
      static if(pred!U) alias process = U;
      else alias process = AliasSeq!();
    }
    alias NewFilter = AliasSeq!(process!(T)...); // do I need the 
AliasSeq here?
}

template RemoveDuplicates(T...)
{
    template keepIt(U) {
       enum isSame(V) = __traits(isSame, U, V);
       enum keepIt = NewFilter!(isSame, T).length  == 1;
    }
    alias RemoveDuplicates = NewFilter!(keepIt, T);
}

Will this work better? You will still have a bunch of NewFilter, 
process, keepIt, and isSame instantiations, all with horribly long 
symbol names. But of note is there is no recursive instantiation patterns.

One thing I noticed, in order to use a property on a static map 
expansion (i.e. call a function with the resulting sequence, or access 
.length), you will need extra parentheses to distinguish the ... token 
from the . token.

Is there an easier/better way to do this with the new feature?

-Steve