Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124889
Precedence: bulk
MIME-Version: 1.0
References: <CAM7F2--PW75jMoZ9Jqfg48gZeWiRhSbYcVUqLOi2OkZnDA6N6Q@mail.gmail.com>
In-Reply-To: <CAM7F2--PW75jMoZ9Jqfg48gZeWiRhSbYcVUqLOi2OkZnDA6N6Q@mail.gmail.com>
Date: Mon, 12 Aug 2024 09:49:05 -0600
Message-ID: <CAAKU0unG1ZOmzE=YnbTTmNpsuJr1PX--79fjByC473KHzN008w@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
To: Lanre <lnearwaju@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: levi.morrison@datadoghq.com (Levi Morrison)

On Sun, Aug 11, 2024 at 4:54=E2=80=AFPM Lanre <lnearwaju@gmail.com> wrote:
>
> Hello,
>
> I=E2=80=99m considering adding some C++ enhancements to the Zend API. The=
se changes would be encapsulated within `#ifdef __cplusplus` guards, so the=
y wouldn=E2=80=99t interfere with the existing C implementation. The primar=
y goal is to provide a nicer interface for extensions while maintaining com=
patibility with C.
>
> Key points:
> - **Struct-based Approach:** Everything will still use structs=E2=80=94no=
 classes or non-public/non-static members.
> - **Isolation:** Any enhancements that can be isolated from the C impleme=
ntation will be, and they will reside in a common `zend_api_cxx` header fil=
e.
> - **Proposed Enhancements:**
>   - Constructors and destructors, along with comparison operator overload=
s for `zval`.
>   - Constructor overloads for common `zval` initializations.
>   - Member methods for common `zval` operations.
>
> I=E2=80=99m happy to implement and maintain these changes. Since this doe=
sn=E2=80=99t affect userland, do you think an RFC is necessary?
>
> Also, if anyone has suggestions or ideas for this C++ API, I=E2=80=99d lo=
ve 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.