Date: Wed, 29 Apr 2026 08:58:46 +0200
On 4/29/26 12:40 AM, Thiago Macieira via Std-Proposals wrote:
> On Tuesday, 28 April 2026 15:12:26 Pacific Daylight Time Sebastian Wittmeier
> via Std-Proposals wrote:
>> Could template member functions, declared in the class together with private
>> extension functions, which change overload resolution, be a small issue?
> Yes, that could cause an ODR violation. You don't need templates for that
> either. Plus, you can get violations without overloads, by using requires
> clauses.
Is the following an example of what you mean with ODR violation?
== Header ==
template<typename T>
class Foo {
public:
Foo() {
A(T()); // dependent lookup, overload resolved at instantiation
}
private:
void A(double);
// void A(int); -> not declared, extended later
}
// If Foo instantiated here -> A(int) does not participate
== cpp ==
private void Foo::A(int) {
}
// If Foo instantiated here -> A(int) does participate
So if in one translation unit Foo is instantiated without seeing A(int)
and in another
Foo is instantiated with seeing A(int), it would be ill-formed (IFNDR).
If you were thinking of a different problem, could you give an example?
I think this problem is similar as that is already the case with free
functions, isn't it?
Though maybe this trap is slightly more easy to trigger... not sure. At
the very least,
this problem didn't exist for class members before and now it does, so I
think that's
worthwhile to mention in the proposal. Good points, thanks!
Regards,
André
> On Tuesday, 28 April 2026 15:12:26 Pacific Daylight Time Sebastian Wittmeier
> via Std-Proposals wrote:
>> Could template member functions, declared in the class together with private
>> extension functions, which change overload resolution, be a small issue?
> Yes, that could cause an ODR violation. You don't need templates for that
> either. Plus, you can get violations without overloads, by using requires
> clauses.
Is the following an example of what you mean with ODR violation?
== Header ==
template<typename T>
class Foo {
public:
Foo() {
A(T()); // dependent lookup, overload resolved at instantiation
}
private:
void A(double);
// void A(int); -> not declared, extended later
}
// If Foo instantiated here -> A(int) does not participate
== cpp ==
private void Foo::A(int) {
}
// If Foo instantiated here -> A(int) does participate
So if in one translation unit Foo is instantiated without seeing A(int)
and in another
Foo is instantiated with seeing A(int), it would be ill-formed (IFNDR).
If you were thinking of a different problem, could you give an example?
I think this problem is similar as that is already the case with free
functions, isn't it?
Though maybe this trap is slightly more easy to trigger... not sure. At
the very least,
this problem didn't exist for class members before and now it does, so I
think that's
worthwhile to mention in the proposal. Good points, thanks!
Regards,
André
Received on 2026-04-29 06:58:52
