I would pin the blame on the implicit conversion from raw pointer types to bool here. We avoid this problem with nullptr and smart pointers, as they are only explicitly convertible to bool.

Not sure what to do about it though, at least this conversion is "narrowing", but that's not enough for plain function calls.


On 20 April 2026 13:25:08 BST, sasho648 via Std-Proposals <std-proposals_at_[hidden]> wrote:
>Bump now I had:
>
>like:
>
>void f(int a, bool d = false);
>
>int f1(int a, int *p = nullptr);
>
>and I called:
>
>int *p;
>
>f(f1(2), p);
>
>
>It compiles and runs "fine" - except the behavior is totally unintended.
>
>It's evil in my opinion.
>
>Obviously I did a mistake putting the second parameter in the first call
>when I wanted it to be part of the f1 call.
>
>It never ever occurred to me until later on when I was checking this part
>of the code for another thing.
>
>On Tue, May 13, 2025 at 12:16 AM Frederick Virchanza Gotham via
>Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On Monday, May 12, 2025, Thiago Macieira wrote:
>>
>>>
>>>
>>> I do think deprecating the decaying of functions to function pointers is
>>> the
>>> correct solution, but the chance of this happening before the entropy
>>> death of
>>> the universe are pretty slim.
>>>
>>>
>>
>> This is what Terry Davis did in his "Holy C" when he was writing TempleOS.
>> He actually managed to turn C into a "just in time" language. I wish he had
>> gotten the help he needed and gotten better, he was an extremely talented
>> programmer and could have contributed greatly to our art with his design
>> and implementation of programming languages and operating systems.
>>
>> https://en.wikipedia.org/wiki/TempleOS
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>