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

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

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)

Do you mean that [basic.def.odr]/16.10 should be

In each such definition, the possibly overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same ~~function~~ entity.

to eliminate the nuances caused by built-in operators?

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)

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.

Do you mean that [basic.def.odr]/16.10 should be

In each such definition, the possibly overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same ~~function~~ entity.

to eliminate the nuances caused by built-in operators?

What would the entity of a built in operator be?

doesn't the first example match [ifndr:basic.def.odr.definition.matches] ?

Do you mean that [basic.def.odr]/16.10 should be

In each such definition, the possibly overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same ~~function~~ entity.

to eliminate the nuances caused by built-in operators?

What would the entity of a built in operator be?

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.

A built-in operator is not an entity.

CWG3229

Should I open another issue for the second case, where two different built in operators are used?

What "two different built-in operators" are used for the second case (assuming you mean the conversion of incomplete class types situation)?

What "two different built-in operators" are used for the second case (assuming you mean the conversion of incomplete class types situation)?

reinterpret_cast and static_cast.

What "two different built-in operators" are used for the second case (assuming you mean the conversion of incomplete class types situation)?

reinterpret_cast and static_cast.

[expr.cast]/5 says that for the first cast it is unspecified whether the static_cast or the reinterpret_cast is used.

[expr.cast]/5 says that for the first cast it is unspecified whether the static_cast or the reinterpret_cast is used.

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.

Navigation Menu

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Activity

safocl commented on Aug 28, 2026

BlowingWind314 commented on Aug 28, 2026

Halalaluyafail3 commented on Aug 28, 2026

safocl commented on Aug 28, 2026

BlowingWind314 commented on Aug 28, 2026

jensmaurer commented on Aug 28, 2026

jensmaurer commented on Aug 30, 2026

Halalaluyafail3 commented on Aug 30, 2026

jensmaurer commented on Aug 31, 2026

Halalaluyafail3 commented on Aug 31, 2026

BlowingWind314 commented on Sep 16, 2026

Halalaluyafail3 commented on Sep 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions