DMD producing huge binaries

[ZombineDev via Digitalmars-d]

On Friday, 20 May 2016 at 12:01:14 UTC, ZombineDev wrote:
> On Friday, 20 May 2016 at 11:40:12 UTC, Rene Zwanenburg wrote:
>> On Friday, 20 May 2016 at 11:32:16 UTC, ZombineDev wrote:
>>> IMO, the best way forward is:
>>> + The compiler should lower voldemort types, according to the 
>>> scheme that Steve suggested 
>>> (http://forum.dlang.org/post/nhkmo7$ob5$1@digitalmars.com)
>>> + After that, during symbol generation (mangling) if a symbol 
>>> starts getting larger than some threshold (e.g. 800 
>>> characters), the mangling algorithm should detect that and 
>>> bail out by generating some unique id instead. The only 
>>> valuable information that the symbol must include is the 
>>> module name and location (line and column number) of the 
>>> template instantiation.
>>
>> Location info shouldn't be used. This will break things like 
>> interface files and dynamic libraries.
>
> Well... template-heavy code doesn't play well header-files and 
> dynamic libraries. Most of the time templates are used for the 
> implementation of an interface, but template types such as 
> ranges are unsuable in function signatures. That's why they're 
> called voldemort types - because they're the ones that can 
> not/must not be named.
> Instead dynamic libraries should use stable types such as 
> interfaces, arrays and function pointers, which don't have the 
> aforementioned symbol size problems.
>
> Since we're using random numbers for symbols (instead of the 
> actual names) it would not be possible for such symbols to be 
> part of an interface, because a different invocation of the 
> compiler would produce different symbol names. Such symbols 
> should always an implementation detail, and not part of an 
> interface. That's why location info would play no role, except 
> for debugging purposes.

@Rene
How do you expect the compiler to know the exact return type, 
only by looking at this signature:
auto transmogrify(string str);

A possible implementation might be this:
auto transmogrify(string str)
{
    return str.map!someFunc.filter!otherFunc.joiner();
}

or something completly different.