Thank you Jens for the reply.

Sorry for the typo to refer §13.6-5 instead of §13.6-5. However, the
reported text from standard was able to clarify it.

Some answers about your comments.

>> ...

> [temp.type] is talking about equivalence of dependent types in general.
> (Note this says "equivalence" not "the same". The latter is applicable
> when nothing is dependent.)
> It just so happens that the equivalence of template-ids is
> an important factor for that.

I see. 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.
And, yes, clear about "equivalent" is not "the same" in contexts with
dependencies.


>> ...

> It says we want to construct something to which the ODR can be applied.
> The ODR can't be applied to non-defining declarations, so the other
> reading doesn't make sense.

Sure, I agree. However, I did not (intend to have) proposed switching the
text to refer declarations instead of definitions.


>> "if two function definitions containing the expressions..." -> should it
mean in the declarative part only of the definition or even in the body ?

> In the body. We want to apply the one-definition rule on the result.

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).


>> I guess that problems may arise by using 'templated functions' (in an
eventual fix of §13.7.6.1-5) instead of 'template functions', because
§6.3-(16.3) refers applying requirements to "names from the enclosing
scope" only for templates, not for templated entities. Of course, the
intent of 6.3-(16.3) also implicitly covers the templated entities included
in a template... but for the two hypothetical definitions referred by
§13.7.6.1-5, they appear as 'the starting point', that is, not caring of
any hypothetical enclosing template to which §6.3-(16.3) would be
applicable.

> Put differently, both hypothetical definitions would be in the same
context,
> so there is no change in interpreting names referring to the "outside"
> between the two hypothetical definitions.

Well, being in the same context is a good candidate for the additional
information to be explicit in §13.7.6.1-5.
On the other hand, if the two expressions start from the same context, why
we should care of specifying "except for the different naming" ? I don't
believe the intent was just about aliases (e.g., see Note 1 in §13.6-4). Am
I missing something here ?
Anyway, I still see a bit cryptic that §13.6-(16.3) would apply to such a
hypotetical context (currently never mentioned) so that, as a consequence,
it applies to the two functions.


>> And then, how a function (definition) may be in a scope involving
template parameters except being a template(d) function member of a
template(d) class... that is why not clarifying 'templated' for these two
functions ?
>> The need of clarifying 'templated functions' seems to derive even by the
fact that we are discussing about some 'equivalence', and two different
definitions for the same non-inline non-templated function violates the ODR
rule (regardless of the sequence of tokens: refer §6.3 [basic.def.odr] -
(15.1)).

> Right, but we want to use the ODR mechanism to compare those
> two hypothetical function definitions. There's no need
> to talk about "templated", I think; we're just using
> the "same tokens -- same meaning" list from the ODR.

On this point, I disagree with a bit of more convinction. I mean, if
§13.7.6.1-5 refers ODR satisfaction, how can we be sure to refer the part
of 'same tokens' (from ODR) without making it explicit we mean templated
functions ? Is it so problematic to add a single word 'template' in
§13.7.6.1-5 ?
And... did I miss the fact that ODR reads somewhere about "same meaning"
instead of "same tokens" ?


> [temp.type] is for declaration matching and similar situations
> where types need to be compared before instantiation.
> In your example, the function template "f" is instantiated when
> that's needed (because you call it from "main"), and the instantiation
> produces a non-dependent function body by substituting "int" for "T"
> everywhere. Since nothing is dependent anymore after this, the special
> rule for decltype(e) in [temp.type] doesn't apply at this stage.

Ok, thank you to clarify, here for sure I miss knowledge about the
definition of 'dependent types'.
Might you be so kind to present a scenario we may need to compare two
decltype(dependent_expr) before instantiations ?
Right now, I may just think about scenarios where the primary goal is to
know whether the ODR is violated,
which would not match with our discussion reaching §13.7.6.1-5 (as it
includes the 'same-meaning' relaxaton).

Mauro.