On Sun, Aug 11, 2024 at 4:54 PM Lanre <lnearw...@gmail.com> wrote: > > Hello, > > I’m considering adding some C++ enhancements to the Zend API. These changes > would be encapsulated within `#ifdef __cplusplus` guards, so they wouldn’t > interfere with the existing C implementation. The primary goal is to provide > a nicer interface for extensions while maintaining compatibility with C. > > Key points: > - **Struct-based Approach:** Everything will still use structs—no classes or > non-public/non-static members. > - **Isolation:** Any enhancements that can be isolated from the C > implementation will be, and they will reside in a common `zend_api_cxx` > header file. > - **Proposed Enhancements:** > - Constructors and destructors, along with comparison operator overloads > for `zval`. > - Constructor overloads for common `zval` initializations. > - Member methods for common `zval` operations. > > I’m happy to implement and maintain these changes. Since this doesn’t affect > userland, do you think an RFC is necessary? > > Also, if anyone has suggestions or ideas for this C++ API, I’d love to hear > them. > > Cheers, > Lanre
I am not opposed, but there are some logistics questions: 1. Since it's for extensions and not core, how will we be sure it is maintained? What will test it? 2. Since it's in core, and C++ is a rapidly evolving language, what will the required C++ version be? What would our policy be on updating it? 3. How will we be sure about edges around language mismatches in C and C++? For instance, they have different rules regarding unions, which we make liberal use of. 4. C++ has many features and some are controversial. Will any be disallowed such as exceptions? There is one part of C++ specifically that I think could be pretty nice if we can figure out all the details: compile-time evaluation of the string hash function. This could make dealing with well-known/compile-time strings easier.
