The ternary operator overhead of ITC for all of its operands

I cannot help myself but struggle to understand why is the ternary conditional's 3rd operand (the false-condition expression) subject to implicit type conversion even when the control condition evaluates to true and vice-versa?

I can probably only reason with the fact that the C language standard specification requires that the operands are "compatible" (I've heard this terminology everywhere, but I am not sure how accurate it is) and just like in any expression, the compiler makes sure that they are. But why is this restriction on the first place? The ternary is not like other operators in that it can freely disregard the expression that will not be evaluated. For other operations it is evident that the operands ought to be of the same type for the particular operation to work as intended.

That would also only make sense if the Implicit Type Conversion occur at compile time, and to be honest, I don't even really know when it takes place. For some reason I cannot find a sane answer to this question, but I did found this article. This article doesn't make any sense to me, particularly this line:

Implicit type conversion in C language is the conversion of one data type into another datatype by the compiler during the execution of the program.

Is it by the compiler, or is it during the execution of the program? I may be an easy one to get confused, but as far as I am aware the compiler has nothing to do during the program's execution.

So, can anyone please explain why is the ITC conversion all that necessary, because to me this yields an unnecessary overhead. Here is a proof-of-concept:

#include <stdio.h>

int main (void)
{
    printf("%zu\n", sizeof( 0 ? 2.0 : 3 ));
   
    return 0;
}

The result is 8.

• Also I asked ChatGPT when does ITC occur and it wrote at run time. I asked it if it is sure and to validate that information and not surprisingly it changed its narrative.

It's important to understand the C evaluation model: the language is defined on an abstract machine in which there is no distinction between "compile-time" and "run-time". There is a partial ordering on observable side-effects .

Converting 3 to 3.0 occurs in the abstract machine if and when the third operand of the conditional operator is evaluated.

The compiler is responsible for producing the same output that the abstract machine would produce. Because this conversion has no side-effect, the compiler could prepare it in advance. For example the compiler might prepare the converted result during compilation to avoid any runtime assembly instruction being needed.

Your sizeof example is not really relevant to this question, as the result of sizeof depends only on the type of the two arguments ; it doesn't depend on the value of the arguments or on which argument might be selected if the conditional were evaluated.