Re: Type assertions without GCC builtins

On Wed, 19 Nov 2025 at 19:44, Peter Eisentraut <peter(at)eisentraut(dot)org> 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