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

[Halalaluyafail3]

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

[safocl]

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]

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?

[Halalaluyafail3]

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?

[safocl]

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

[BlowingWind314]

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.

[jensmaurer]

A built-in operator is not an entity.

[jensmaurer]

CWG3229

[Halalaluyafail3]

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

[jensmaurer]

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

[Halalaluyafail3]

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.