Repository navigation
CWG3229 [basic.def.odr] Mixing built in operators with overloaded operators or mixing different built in operators for the same token sequence in inline functions #994
Description
Full name of submitter (unless configured in github; will be published with the issue): Jay Ghiron
Reference (section label): [basic.def.odr]
Issue description:
Consider the following two translation units:
//TU 1
struct S{};
inline S foo(){
return S(),S();
}
//TU 2
#include<iostream>
struct S{};
S operator,(S,S){
std::cout<<"called\n";
return{};
}
inline S foo(){
return S(),S();
}This should probably be IFNDR, but there does not actually appear to be anything that makes it ill-formed. "In each such definition, the overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same function." [basic.def.odr]/16.10 is the closest thing, but it appears that it assumes two functions are used. Unary operator& is another scenario where a built in operator can be mixed with an overloaded operator. Additionally, consider the following two translation units:
//TU 1
struct B;
struct C;
inline B*bar(C*p){
return(B*)p;
}
//TU 2
struct A{int x;};
struct B{int y;};
struct C:A,B{};
inline B*bar(C*p){
return(B*)p;
}This should probably be IFNDR as well, but there does not appear to be anything that makes it ill-formed. See also: #990
Activity
safocl commentedon Aug 28, 2026
It's as if "ill-formed" behavior is included in "IFNDR", isn't it?
(In other words, it doesn't prohibit the diagnostic from being issued, but it doesn't require it either)
BlowingWind314 commentedon Aug 28, 2026
Do you mean that [basic.def.odr]/16.10 should be
to eliminate the nuances caused by built-in operators?
Halalaluyafail3 commentedon Aug 28, 2026
I do not understand the point you are making. But as far as I understand IFNDR programs are a subset of ill-formed programs. Every program that is IFNDR is ill-formed, but not every program that is ill-formed is IFNDR.
What would the entity of a built in operator be?
safocl commentedon Aug 28, 2026
doesn't the first example match [ifndr:basic.def.odr.definition.matches] ?
BlowingWind314 commentedon Aug 28, 2026
Adding only "possibly" seems to work well. A built-in operator does not refer to any function, while the overloaded one does, which violates this rule.
jensmaurer commentedon Aug 28, 2026
A built-in operator is not an entity.
[-][basic.def.odr] Mixing built in operators with overloaded operators or mixing different built in operators for the same token sequence in inline functions[/-][+]CWG3229 [basic.def.odr] Mixing built in operators with overloaded operators or mixing different built in operators for the same token sequence in inline functions[/+]jensmaurer commentedon Aug 30, 2026
CWG3229
Halalaluyafail3 commentedon Aug 30, 2026
Should I open another issue for the second case, where two different built in operators are used?
jensmaurer commentedon Aug 31, 2026
What "two different built-in operators" are used for the second case (assuming you mean the conversion of incomplete class types situation)?
Halalaluyafail3 commentedon Aug 31, 2026
reinterpret_cast and static_cast.
BlowingWind314 commentedon Sep 16, 2026
[expr.cast]/5 says that for the first cast it is unspecified whether the
static_castor thereinterpret_castis used.Halalaluyafail3 commentedon Sep 16, 2026
I am aware, see the issue I linked originally. There is no wording to say that if the reinterpret_cast interpretation is used then it is an ODR violation.