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