>> Is it problematic to specify this detail on the 'body' ? A single word that would faster lead the reader mind on the correct way.
>> Moreover, I didn't get what "on the result" exactly means. The best guessing is on the two definitions.
>> Anyway, I still believe that more information should be provided, for example what else is in these two definitions (likely, nothing else),

>> and maybe even the fact that we mean two definitions of the same function (despite, of course, a disussion about ODR is meaningless if not so).

> So, you seem to agree that's clear enough.

Unfortunately, not so. I really believe it would be better to specify:

a) definitions are for the same function. This adds consistency IMHO, despite

  being the only possible way to provide a meaning to the application of ODR... but

  who knows in the future (or currently) we have parts where two functions might

  satisfy the ODR just because of a different declarative part ?

b) expressions are meant to be in the body, one per each definition.

c) either specify 'bodies containing only corresponding expression' or specify that the ODR rules

  are intended to be considered only for the expressions. Otherwise, you know, the

  text reads "two ... definitions ... would satisfy the one-definition rule" which IMHO has

  one meaning only, that is, the overall functions, in turn not possible to check without

  knowing all function features.

>> And... did I miss the fact that ODR reads somewhere about "same meaning" instead of "same tokens" ?

> Yes.
> [basic.def.odr] p15.4 is "same tokens".
> p15.5 is "same meaning" (of those tokens).

Perfect, thanks, I just misinterpreted your previous "same tokens -- same meaning",

wrongly supposing the dash might mean OR. My bad.

>> Anyway, I still see a bit cryptic that §6.3-(16.3) would apply to such a hypotetical

>> context (currently never mentioned) so that, as a consequence, it applies to the two functions.

> For example, there might be references to global variables or
> global typedefs.  Those must name the same things for both
> hypothetical definitions.

I totally agree, I remember a stackoverflow discussion where a different macro definition

would lead to provide different meaning to the same template definition code in two

different translation units, so violating the ODR.

However, here my comment was focused on the applicability of [basic.def.odr]-(16.3) to the two definitions:

d) for consistency, the function (with two definitions) should be indicated at least as 'templated'

    in [temp.over.link]-5, in the same perspective of my point c) above, in order to apply

    the intended part of the ODR rules.

e) even better, to indicate the function as 'template' (same wording of [temp.over.link]-5),

    otherwise a non-clear definition of the hypotethical context might not lead to consistently

    apply [basic.def.odr]-(16.3) to a just-templated function in such a template context.

> There are examples in [temp.over.link] p5 (example 3) that
> might clarify.

Yes, thanks to highight, they were already clear.

> Another example:

> template<class T>
> void f(decltype(T() + T()));

> template<class U>
> void f(decltype(U() + U{}));

> Are these two declarations declaring the same function template?
> The difference in template parameter names is ok, but there
> are different tokens involved for the first parameter type,
> so those declarations declare different overloads.

Sure, clear, "()" vs "{}" -> different tokens.

Ok, according to your answers, now the overall intent in

the chain [temp.type]-4 (decltype(e)) -> [temp.over.link]-5 -> [basic.def.odr]

is better focused on the declarations only. Anyway, please, consider my

comments a)-e) above.

Moreover:

Any comment on this ?