On Mon, Aug 12, 2024 at 9:49 AM Levi Morrison <levi.morri...@datadoghq.com> wrote:
> 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. > 1. As for testing, we can implement either a second zend_test extension or add the tests to the current one. 2. C++ is indeed a rapidly evolving language, I suggest starting with a conservative approach by targeting a stable C++ version that balances modern features with broad compatibility—C++17 or C++20 could be good candidates. As for updating the required version, we could establish a policy where we review the C++ version every couple of years, aligning it with broader trends in C++ adoption and compiler support across platforms. This would help us avoid potential fragmentation or compatibility issues. 3. As long as we stick to the struct based approach, we should be fine regarding the common edge cases. The idea is to keep the structs compatible with C while supporting C++ features 4. To maintain a clean and consistent API, I suggest we disallow certain C++ features like exceptions. Exceptions could introduce complexity and unpredictability, especially when mixed with C's error handling mechanisms. Overall, the goal is to use C++ to enhance the API without compromising the stability and simplicity of the C core. We can focus on C++ features that bring clear benefits, such as stronger type safety and cleaner abstractions, while avoiding those that might introduce unnecessary complexity. Cheers, Lanre
