Problems with Template codegen

[kris]

Chris Nicholson-Sauls wrote:
> kris wrote:
> 
>> At this time, D templates are a bit finicky when it comes to argument 
>> matching -- IFTI matching, to be explicit. For example:
>>
>> # uint locate(T) (T[] source, T match, uint start=0);
>> #
>> # locate ("wumpus", 'p', 1);
>>
>> will not compile because '1' is an integer literal, and does not match 
>> the template parameter 'uint'.
>>
>> To get around this, template writers will revert to tricks like this one:
>>
>> # uint locate(T) (T[] source, T match, uint start=0);
>> #
>> # uint locate(T, U=uint) (T[] source, T match, U start=0)
>> # {
>> #     return locate!(T) (source, match, start);
>> # }
>> #
>> # locate ("wumpus", 'p', 1);
>>
>>
>> See what's going on? There's a stub added, which marshalls (for want 
>> of a better term) the 'int' argument  across. This is done to (a) 
>> permit use of both int & uint arguments and (b) to avoid template 
>> duplication for both int and uint types.
>>
>> So, that's a current shortcoming of IFTI -- but it's one that we hope 
>> will be fixed. Moving onto the primary concern ...
>>
>> As one would expect, the DM compiler generates code for the stub to 
>> re-push the arguments and call the /real/ implementation. However, in 
>> /all/ cases we really want to eliminate the stub since it is nothing 
>> but a pass-through call; one generated to workaround what seems to be 
>> an IFTI limitation.
>>
>> Unfortunately, the DM tools will remove the stub /only/ when you use 
>> the -inline switch. This is a very powerful switch, causing all kinds 
>> of inlining to occur -- in some cases, things which many engineers 
>> would balk at. Inline is often just too /big/ a switch to pull.
>>
>> However, we'd still like darned stubs to be removed from the codegen. 
>> How do we get that to happen?
> 
> 
> One notion would be to use the (T, U=uint) notation for the 'real' 
> template and leave the stub out, but it defeats the original intent 
> somewhat and doesn't really *solve* the problem.

That's right, because you wind up with multiple instantiations of the 
same template, just for the same of supporting int type-variations.


> I'd say IFTI just 
> needs to incorporate implicit casting rules such as int->uint and that 
> would be a solution.

Right. But are we supposed to do in the interim?

- Kris