Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124901 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 78E9D1A00B7 for ; Mon, 12 Aug 2024 18:05:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1723486008; bh=Kx4EfH8jOrt1UWgX/Wwac6w7arcFO/Z+lRGHLKhuSfo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jRKXSTJnDJSPTHuJazrr15fYHrfim+vVYAbXk2la7RUPSB0Slv2Y6AZ/IxPLIQlgT mCHxwIV5n9shg6yx+QZIBhHnMlOcmXm3fADisTlUuOlhAAzv81Og/rrhCV/WbTLpbu AoC8otTnvcnkw7au4WCkrTXmsCOfuX8oypAQrAPt35YEasF8S+giQdotiD7zuEHFsD 4UuX6Mioi0aE73TyzqL92wLAU5VAHfukXfxCPmb17fKP3nhcFWYoosdqHeHMwPAlxd TghDQVlK6ryut256COW3R8Og5AKdN46m2vqx1doqW0Ze5DDvfbsw+YX4RLd4nWZs2h w41GgNiJag2xA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5456218007D for ; Mon, 12 Aug 2024 18:06:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 12 Aug 2024 18:06:46 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3db50abf929so3484191b6e.2 for ; Mon, 12 Aug 2024 11:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723485901; x=1724090701; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JqvLK/APWvTuweqUT/UXld+Nobh9gQwsJ4F06HmZ6X0=; b=cgSY3As+hU6UKyTEOU//HFSnYkK3/csKcTXHrRUZ097Y3py/hxd6K4+51611M+/3jd VjbOu+2xBUkfE+1eTq5xv8jYsaPxsMrKAektO3oTbNSyTc1wNoE9hlIJdYkmFr6sJsyP Q+wCpwsby7G6HtYXzCC/pTJX+sQha1C4DqFxzj2OpODmoACc+nvmci2A5OoJACWYTou/ 5AMicPrEIs5kk2aGpYs05SHVZ3HPLsTYZ/dXdFug62CUfUeHXvCiVjwOOolFVmPOeExC 4fkzDbzbIzRIdweefV+kbm/weNEcDh+SSLxNkIPHKFYfaAQgSr8lbJ3ELWRt2+NXQS0K akgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723485901; x=1724090701; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JqvLK/APWvTuweqUT/UXld+Nobh9gQwsJ4F06HmZ6X0=; b=dAi/zybEZIX1eiqmlVnlq0rjvZw8dOEzLGn8VKVAKEo3Hji34JERInFeh1ZcM8xjoP kCpKvYJSTjfbLNFABN5gkAzRMJvg0j6wzPbX1fi7YPZxbSR72tycy4jCcvdf4ly9flsm L0ZJvHtpuKOxyy0F2JGvSID1oaYVgcf+sk/tV/WOSOuSmZNLKtM9rPyMo7mAdvacjopD JBPtzPZ7ysSuPr0s38RzNZ1AVwDzvL51PopJAYDSLemHDW1jbXHeLB+0fbeEZfj40NeU S02tNFSO+1uEzyWkO38nBAjkyCu2Y5o/LvGh5CjuOeP8obyfuEK0E0vZQ4i6l4NaXEFb gLFQ== X-Gm-Message-State: AOJu0YzZ+XFxvWyn5pY2FhKw/1q4RzBifhMznzS+WAJUAcpcg/nyoJM0 v/Y0nLANTCAcExXTQpYRwKoNsjrahE3JipMBAF+040680Jn/zyKRh5vaTUHUNbTrLLux9wD0tTo ZS531PfoWknVWivLSt0pb3J0g2ZA= X-Google-Smtp-Source: AGHT+IEdzSXpUbzv2PofDpOKdYBNk5ePiilYdNN+kOuNrF7BGY9ynh6eiQjPREPY/hcm1EeHb6ZZOhU0TbVVvh22bH8= X-Received: by 2002:a05:6808:1689:b0:3d6:2ff3:937 with SMTP id 5614622812f47-3dd1eec4b19mr1293309b6e.40.1723485901252; Mon, 12 Aug 2024 11:05:01 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 12 Aug 2024 12:04:50 -0600 Message-ID: Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API To: Levi Morrison Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000eb6f53061f8054eb" From: lnearwaju@gmail.com (Lanre) --000000000000eb6f53061f8054eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 12, 2024 at 10:19=E2=80=AFAM Lanre wrote: > > > On Mon, Aug 12, 2024 at 9:49=E2=80=AFAM Levi Morrison > wrote: > >> On Sun, Aug 11, 2024 at 4:54=E2=80=AFPM Lanre wrot= e: >> > >> > Hello, >> > >> > I=E2=80=99m considering adding some C++ enhancements to the Zend API. = These >> changes would be encapsulated within `#ifdef __cplusplus` guards, so the= y >> wouldn=E2=80=99t interfere with the existing C implementation. The prima= ry goal is >> to provide a nicer interface for extensions while maintaining compatibil= ity >> 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 >> 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=E2=80=99m happy to implement and maintain these changes. Since this = doesn=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= 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 o= r > 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=E2=80=94C++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 compatib= le > 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 mechanism= s. > > > 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 --000000000000eb6f53061f8054eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 12, 2024 at 10:19=E2=80= =AFAM Lanre <lnearwaju@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">


<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 12, 2024 at 9:49=E2=80=AFA= M Levi Morrison <levi.morrison@datadoghq.com> wrote:
On Sun, Aug 11, 2024 at 4:54=E2=80= =AFPM Lanre <ln= earwaju@gmail.com> wrote:
>
> Hello,
>
> I=E2=80=99m considering adding some C++ enhancements to the Zend API. = These changes would be encapsulated within `#ifdef __cplusplus` guards, so = they wouldn=E2=80=99t interfere with the existing C implementation. The pri= mary goal is to provide a nicer interface for extensions while maintaining = compatibility 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 impl= ementation will be, and they will reside in a common `zend_api_cxx` header = file.
> - **Proposed Enhancements:**
>=C2=A0 =C2=A0- Constructors and destructors, along with comparison oper= ator overloads for `zval`.
>=C2=A0 =C2=A0- Constructor overloads for common `zval` initializations.=
>=C2=A0 =C2=A0- Member methods for common `zval` operations.
>
> I=E2=80=99m happy to implement and maintain these changes. Since this = doesn=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= love to hear them.
>
> Cheers,
> Lanre

I am not opposed, but there are some logistics questions:
=C2=A01. Since it's for extensions and not core, how will we be sure it= is
maintained? What will test it?
=C2=A02. Since it's in core, and C++ is a rapidly evolving language, wh= at
will the required C++ version be? What would our policy be on updating
it?
=C2=A03. 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.
=C2=A04. 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 evo= lving language, I suggest starting with a conservative approach by targetin= g a stable C++ version that balances modern features with broad compatibili= ty=E2=80=94C++17 or C++20 could be good candidates. As for updating the req= uired 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 fragm= entation or compatibility issues.
3. As long as we stick to the s= truct based approach, we should be fine regarding the common edge cases. Th= e idea is to keep the structs compatible with C while supporting C++ featur= es
4. To maintain a clean and consistent API, I suggest we disall= ow certain C++ features like exceptions. Exceptions could introduce complex= ity and unpredictability, especially when mixed with C's error handling= mechanisms.=C2=A0


Overa= ll, the goal is to use C++ to enhance the API without compromising the stab= ility and simplicity of the C core. We can focus on C++ features that bring= clear benefits, such as stronger type safety and cleaner abstractions, whi= le avoiding those that might introduce unnecessary complexity.
Cheers,
Lanre=C2=A0

=
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

C= heers,
Lanre
--000000000000eb6f53061f8054eb--