A modest proposal: eliminate template code bloat

[Artur Skawina]

On 04/08/12 18:14, Andrei Alexandrescu wrote:
> On 4/8/12 10:59 AM, Artur Skawina wrote:
>> On 04/08/12 17:20, Dmitry Olshansky wrote:
>>> On 08.04.2012 18:21, Artur Skawina wrote:
>>>> On 04/08/12 13:01, Dmitry Olshansky wrote:
>>>>> 3. After any function was generated compiler checks an entry in the duplicate table that matches size, followed by matching checksum and only then (if required) doing a straight memcmp. If it happens that there is a match compiler just throws generated code away and _aliases_ it's symbol to that of a matched entry.
>>>>> (so there has to be an alias table if there isn't one already)
>>>> [...]
>>>>> Thoughts?
>>>>
>>>> Don't forget that this needs to work:
>>>>
>>>>      static auto f(T)(T a) { return a; }
>>>>      assert(cast(void*)&f!int!=cast(void*)&f!uint);
>>
>>> A reference to spec page plz.
>>
>> A reference to *a* D spec, please...
>>
>> There isn't one, but that does not mean that common sense does
>> not need to apply.
> 
> Doesn't apply to C++.

Well, let's say it isn't specified. "Functions-are-not-objects" allows
the compilers that merge the bodies to get away with it, because it's
not explicitly illegal. But that does not mean that returning a different
random pointer, which just happens to point to another identical code
sequence, is a good idea.


On 04/08/12 18:30, Dmitry Olshansky wrote:
> There is common sense and that is (in my book):
> don't tie up compiler's hands for no benefit.

In this case the benefit from not requiring unique function addresses
isn't very large (it only matters iff the address is taken).

Hmm, as long as the returned pointer points to functionally identical
code, often everything will still be fine. In other cases doing this
optimization *at all* will cause trouble. And i think it should be
done (the benefits are obvious), An "unique" function attribute would
be the solution; that would let us eat the cake, except when we want
to have it. :)

artur