Thank you Jens.

I will start from your last statement:

> The standard is not a tutorial.

I agree, and I hope not to hurt your patience, as I may have a different
sensivity
on the correct level of needed clearness.
Anyway, I will try to focus on the consistency first, as witnessed by the
recent interaction
that led to https://cplusplus.github.io/CWG/issues/2948.html, where I
agreed on several
simplifications in the way you applied proposed changes.
Hope my feedbacks on this and future topics, aimed at contributing to
improve,
will be appreciated :-)
Philosiphically speaking, a robust level of consistency is also on the same
page
with the current effort to make C++ safer. Potential ambiguities in
specifications
are evil in safety contexts. Then, I agree we may relax when it is only
matter
of moving toward a tutorial-level of clearness, with a subtle boundary
between
clearness and consistency. Again, I hope to correctly focus only on the
latter.


In the meanwhile, I see [temp.over.link] became §13.7.7.2 instead of
§13.7.6.1, I will try to always use [temp.over.link] in the following.


>> 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:

>> However, §13.6 is under §13 and the part name is [temp.type],
>> therefore I would suggest to introduce the more general scope
>> of §13.6 with some words.

Any comment on this ?


Finally, just an additional confirmation on Note 3 of [temp.over.link]-5,
with the
examples A<42> and A<40+2>.
There, A is intented to be a concept, right ? (using [temp.type]-(2.1))


Mauro.