On Monday, 17 July 2017 at 18:42:36 UTC, H. S. Teoh wrote:
Besides the symbol problem though, does the template
instantiation explosion problem imply as many duplicated
function bodies corresponding to the new type symbols?
That's a different, though somewhat related, issue. I have
some ideas on that front, but for now, Rainers' PR addresses
only the problem of symbol length. So the next task after his
fix is merged is to tackle the larger problem of how to improve
the implementation of templates.
[...]
Often, this results from templates that contain helper code
that's independent of the template parameters, or dependent
only on a subset of template parameters. For example:
Yeah, I think this is the second best optimization for symbol
names after using references for duplicates symbol subnames.
One thing you didn't mention is that this also creates a lot of
useless duplicate for Voldemort types in template functions that
don't depend on (all of) the functions parameters. For instance,
looking at the code from the OP's issue:
auto s(T)(T t)
{
struct Result
{
void foo(){ throw new Exception("2");}
}
return Result();
}
void main(string[] args)
{
auto x = 1.s.s.s.s.s;
x.foo;
}
foo mangles to a super long symbol, even though the actual symbol
should be something like
moduleName.s!(__any_type)(__any_type).Result.foo
Actually, it's a little more complicated than that, because s
might have overloads the compiler is not aware of, which means it
doesn't trivially know that T doesn't matter to result.
Still, pretty sure there are optimizations to be had there.
One possibility would be to allow the coder to give unique
subnames to functions. For instance
int add.withInts(int n1, int n2)
float add.withFloats(float n1, float n2)
This would allow the compiler to assume that a function's
mangling is unique, without having to worry about overloads and
other templates, and therefore skip the unnecessary parameters
the function's Voldemort type.
