These commits implement the remaining planned template types. Namely, classes, unions, and interfaces. In addition, approximately a dozen new tests have been added for these kinds of templates.
The implementation is fairly straight forward. What was templateLiftStruct has become templateLiftAggregate and handles all the new templates, which means the amount of new code is relatively low.
Attention, perhaps, should be drawn to the changes at the top of rewriteSuperIdentifier at classresolver.d:135.
ir.Type rewriteSuperIdentifier(ref ir.Exp e, ir.Class _class)
{
auto lookupScope = _class.myScope.parent;
if (lookupScope.node.nodeType == ir.NodeType.TemplateInstance) {
lookupScope = lookupScope.parent;
}
assert(lookupScope !is null);
If unfamiliar this code gets the Store for the parent class by looking above its scope. This is already not a super clean solution (although it's relatively small and innocuous as such things go) as noted by the pre-existing comment. Because in the case of TemplateInstances, the scope that contains the template parameters etc will be above the instance's scope, and not the top level scope it's been instantiated in, this just bumps it up one scope.
I didn't think this justified a major refactoring, as it's fairly contained, but I figured I would bring it up.
Finally, attention should be brought to this commit over on the Docs repository. This updates the TVPL documentation to note that one can use templates for classes, interfaces, and unions in much the same manner as the detailed struct instructions. I didn't think it worth going into more detail than that, as as far as template features go, there's no differences between them.
bhelyer
commented
6 years ago 
These commits implement the remaining planned template types. Namely, classes, unions, and interfaces. In addition, approximately a dozen new tests have been added for these kinds of templates.
The implementation is fairly straight forward. What was
templateLiftStructhas becometemplateLiftAggregateand handles all the new templates, which means the amount of new code is relatively low.Attention, perhaps, should be drawn to the changes at the top of
rewriteSuperIdentifieratclassresolver.d:135.If unfamiliar this code gets the
Storefor the parent class by looking above its scope. This is already not a super clean solution (although it's relatively small and innocuous as such things go) as noted by the pre-existing comment. Because in the case ofTemplateInstances, the scope that contains the template parameters etc will be above the instance's scope, and not the top level scope it's been instantiated in, this just bumps it up one scope.I didn't think this justified a major refactoring, as it's fairly contained, but I figured I would bring it up.
Finally, attention should be brought to this commit over on the Docs repository. This updates the TVPL documentation to note that one can use templates for classes, interfaces, and unions in much the same manner as the detailed struct instructions. I didn't think it worth going into more detail than that, as as far as template features go, there's no differences between them.