On Mon, Aug 12, 2024 at 10:19 AM Lanre <lnearw...@gmail.com> wrote:
> > > 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 > Also I already implemented a compile time version of the string hash function (for one of my extensions), feel free to use it if you need ( https://gist.github.com/oplanre/e384ed2a4c0fea698ed0e15d24157611) but it most likely won't be part of this PR/RFC Cheers, Lanre
