"temporary" templates

[Steven Schveighoffer]

On 11/26/19 1:35 PM, Stefan Koch wrote:
> On Tuesday, 26 November 2019 at 17:03:04 UTC, Steven Schveighoffer wrote:
>> Every time you instantiate a template, it consumes memory in the 
>> compiler for the duration of compilation.
>>
>> [...]
> 
> Ahh.
> 
> I've  been working on this particular  problem a few years ago.
> In _general_ it's not possible to categorize a template  as being 
> temporary or  not.
> For language semantic reasons it is a requirement  for every 
> re-instantiated template to forward  to  exactly the same symbol as was 
> generated during the first instantiation.

If the template ends up being an alias or an enum, then I don't know why 
we need the templates used to get there to stay in memory. In my 
example, the "SumAllHelper" template is an implementation detail. Nobody 
ever actually uses it, just SumAll does. I can understand why SumAll 
instantiations must refer to the exact same thing, but once SumAll is 
done evaluating, why do we need the SumAllHelpers it used?

Can you give me an example where this breaks down if we throw it away?

> 
> The solution that  I came up with is to enhance CTFE to be able to take 
> types as regular function arguments, and relax the semantic constraints 
> on those type-functions.

If CTFE can take over the job of things like NoDuplicates, it might be 
an alternative solution. In fact, exactly what I want is for CTFE-like 
behavior -- once the function is over, everything used to make the 
return value can be garbage.

In fact, using CTFE, I get:

size_t SumAllHelper(size_t val)
{
     size_t result = 0;
     while(val > 0)
        result += val--;
     return result;
}

enum SumAll(size_t x) = SumAllHelper(x);

Memory usage: 51MB. Way way better (and runs faster BTW, not 
unexpectedly). But of course CTFE cannot manipulate types like this, 
which is what I gather is your solution. NoDuplicates would be trivial 
(just call sort and filter adjacent duplicates!) if we could use CTFE.

The benefit of instrumenting existing templates, however, may be that we 
don't have to change much code. This in itself is not so much a huge 
deal, because something like NoDuplicates could potentially be just 
reimplemented and the usage doesn't change.

> If there is sufficient interested I can build a proof-of-conecpt.

I'm always interested in something that reduces compiler memory 
footprint! I'm pushing the upper limits of my RAM, and having to 
redesign my projects to fit the compiler's needs is painful.

-Steve