Re: [DISCUSSION] C++ Enhancements in Zend API

From: Date: Mon, 12 Aug 2024 15:49:05 +0000
Subject: Re: [DISCUSSION] C++ Enhancements in Zend API
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-124889@lists.php.net to get a copy of this message
On Sun, Aug 11, 2024 at 4:54 PM Lanre <lnearwaju@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.

« previous php.internals (#124889) next »