On Wed, 19 Nov 2025 at 19:44, Peter Eisentraut <[email protected]> wrote: > I did not consider C++. I'm unsure what to do about it. For the C type > system, "compatible" is term of art, and swapping > __builtin_types_compatible_p for _Generic is semantically equivalent. I > don't have the C++ experience to know what exactly std::is_same is, but > I don't know that we want to expose ourselves to requiring types to be > *both* C-"compatible" and C++-"same" without more guidance.
The cases in the "example" section on cppreference.com all seem very sensible[1]. I'd say if there's some difference with the generic one, I don't think we'll care about that difference in practice. > In your patch, you also rewrite the unconstify() and unvolatize() > macros. At least in my head, these were initially modeled as C versions > of C++ const_cast. So it seems morally imperative to keep that > association. ;-) You mean use const_cast in c++ instead of a C-style cast? Would you still want to keep the static asserts. > I don't know what the aim of the C++ support might be. Is there a > chance that with the right set of changes, for example, "lib/ilist.h" or > "lib/pairingheap.h" could be used under C++? I think for those headers you mention it shouldn't matter for functionality, because the functionality added by the _Generic is optional type checking. But for my proposal for nicer hash initialization macros it would be a requirement[2]. [1]: https://en.cppreference.com/w/cpp/types/is_same.html [2]: https://www.postgresql.org/message-id/flat/aS2b3LoUypW1/Gdz%40ip-10-97-1-34.eu-west-3.compute.internal
