DMD producing huge binaries

[ZombineDev via Digitalmars-d]

On Friday, 20 May 2016 at 15:39:18 UTC, Rene Zwanenburg wrote:
> On Friday, 20 May 2016 at 12:08:37 UTC, ZombineDev wrote:
>> @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.
>
> I was thinking of something along the lines of this:
>
> =======
> size_t frobnicate(int i)
> {
> 	return 0;
> }
>
> auto frobnicator(T)(T t)
> {
> 	static struct Result
> 	{
> 		int index;
> 		
> 		size_t front()
> 		{
> 			return frobnicate(index);
> 		}
> 		
> 		enum empty = false;
> 		
> 		void popFront()
> 		{
> 			++index;
> 		}
> 	}
> 	
> 	return Result(t.index);
> }
> =======
>
> Automatically generating a header with DMD gives me:
>
> =======
> size_t frobnicate(int i);
> auto frobnicator(T)(T t)
> {
> 	static struct Result
> 	{
> 		int index;
> 		size_t front();
> 		enum empty = false;
> 		void popFront();
> 	}
> 	return Result(t.index);
> }
> =======
>
> Now frobnicator returns a different type for the same T 
> depending on whether you're using the .d or the .di file. I'm 
> not sure if this is a problem, but it sounds like something 
> that can come back to bite you in edge cases.

The only issue is code bloat. It also happens with separate 
compilation, becuase the compiler can't know if the template has 
already been instantiated in a different compilation unit.
Only in a single compilation unit/invocation the compiler can 
reliably see all the places where the same template instance is 
used. In that case, the actual mangled name shouldn't matter, 
AFAIU.