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.