On Mon, Aug 12, 2024 at 9:49 AM Levi Morrison <[email protected]>
wrote:
> On Sun, Aug 11, 2024 at 4:54 PM Lanre <[email protected]> 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