Q: What are the rules for emitting template code?

[Fawzi Mohamed]

On 25-ott-10, at 18:04, Steven Schveighoffer wrote:

> On Sun, 24 Oct 2010 00:06:23 -0400, Austin Hastings <ah08010-d at yahoo.com 
> > wrote:
>
>> Howdy,
>>
>> This is a bit involved, so bear with me.
>>
>> Suppose I have a template, Decider(Args...) and some other  
>> templates, Option1(...), Option2(...), etc.
>>
>> The job of Decider() is to decide, based on the given parameters,  
>> which of the possible OptionN templates to use.
>>
>> Decider uses "static if" and some builtins and maybe some CTFE to  
>> determine its result.
>>
>> Now:
>>
>> How much can Decider ask of one of the Option templates without  
>> that template being expensively realized?
>>
>> Alternatively:
>>
>> What parts of an Option template have to be realized for Decider to  
>> do its job?
>>
>> In particular:
>>
>> If Decider uses Option1.sizeof, does any Option1 code get emitted?
>>
>> If Decider uses some external function that makes use of type  
>> aliases in Option1, (example:  Option1() { alias byte value_t; } )  
>> does any Option1 code get emitted?
>>
>> If Decider uses some function defined inside the same module with  
>> Option1, but NOT inside of Option1, does any/all of the Option1  
>> code get emitted?
>>
>> If Decider uses a static method of Option1, does any more of the  
>> Option1 code get emitted?
>>
>>
>>
>> Obviously, I am trying to ... decide ... how to do compile time  
>> selection. But I'm also just a tad curious at the internals of the  
>> template engine.
>
> One of the major problems with the template system IMO is compile- 
> time templates (that is, templates that are only used at compile  
> time) are emitted into the executable, even though they are not used.
>
> Take for example, isForwardRange(R).  A function like this:
>
> void foo(R) if (isForwardRange!R)
>
> is going to instantiate isForwardRange!R, which may instantiate  
> other templates to check to see if isForwardRange is true.  But all  
> these things end up in the executable, even though they aren't used.
>
> Now, if you are concerned about executable footprint, this problem I  
> think will eventually be solved (not sure if there is a bug report,  
> but I think I've brought it up before, and the consensus is that it  
> should not end up in the exe).  If you are concerned that the  
> runtime of the *compiler* might be too long, then I'm afraid you are  
> just going to have to deal with it.  Everything in a compiled  
> language is focused first on the resulting executable.  It's  
> perfectly normal for a compiler to take extra time compiling to make  
> the executable more efficient.
>
> -Steve
I find that having no clear rule to where a template is emitted when  
compiling several files at once is a larger problem.
I would much prefer to have something that follows some rules like:
sort imports:
if a includes b and b does not include a: a>b
if a includes b and b does include a: order a,b using lexicographic  
ordering of their module name
if b includes a (and a does not include b): b>a
else neutral

when emitting a don't emit any template that was instantiated by  
modules included that come before a, and *only* those: emit all  
remaining instantiations that are required by a.

Yes this is more complex, and emits a bit more than now, but it would  
make incremental compilation using several files at once *so much*  
easier.

Fawzi