Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124898 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 8E71D1A00B7 for ; Mon, 12 Aug 2024 17:29:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1723483900; bh=SXntfyJoOCSNbqQqNFbma9XDX0u1i/2QttVni7c3YnQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EN4XF7If9CJVb6AxzZpHdbXHnT+YNzTbAMMep/tWTn03ZMt6qXOwuj2J7k+Ag+bLi 9fw60TQwM5xgThoinFcQ5+L34ZolztiLbpqzm8vA5AudvS2A4IBFZyHQDUZ45ip52a DSipq2HRH5oB57B0NZqNrvcUyhPWOGp0+qCq0que07Ws75NqyJuNULcMNoRpUyIPRa MLY5ZgYiMpP5YfnPEdl9pf22KcU3jB19sUOP7lIijLN4O85s1ixlrpuYXd3zEybYy9 LtugxifQNrqa6XIL9WhESNNBtaVY+yg/64dJc/Xi+yZoP+3j9FQTjZnJE3qCn74qZG hQ2/BUafUn++A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6E37718007C for ; Mon, 12 Aug 2024 17:31:39 +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_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (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 17:31:38 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2cb576db1c5so3031814a91.1 for ; Mon, 12 Aug 2024 10:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723483793; x=1724088593; 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=f4/ZdAwexZJakMMIJpONAYdu8MQmiwas/YejLbWTLP4=; b=UEWSE/dufj0yrgR+XiAeqnk+Gtfbp7bPYnAe2PkFVRu4etMjwVCtle7uLXz7rQb6uE 6JwsLCU3q0IY36vn+joPEM0LutLKQvrtw3IgeP+EA+AYUugJGoI92FGEaAatsG9TMZsG TGjKxeGVNy50RvN6hd1Lp8Hc7rbieKfD7z6lv1ZEH7z5zXoWkNpPxwlCzUhhBawmWW/q 0zBALQQFsZflJHmgzatQRa/aoUDNebQtqFQzQ5ORY2h8Nh4rJ7ogfFj6pX07ernUoMzJ 91Q8mBDGc8J0DLUzR7aiV1xPeotzASDu3d1DXd71MfpaQCz92v5X5v2gnW1Rk0DzPm5F iqlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723483793; x=1724088593; 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=f4/ZdAwexZJakMMIJpONAYdu8MQmiwas/YejLbWTLP4=; b=Yb063av42Hc89I81qWW5TD4Y6k0/73tysthao/BKSPThgL6/vpEfCM3UAiY4EebEmU bMKClI1IJNqmxXCtKP+rkvGEw8cB/xxqadkoTUmrBnia4ns1GB+C2oRag8rTgXYH7Qu8 b2CbDWP3CXn022SexqP256NoRY0mYKZstqMXlTks63wzdKufc2TwLLqFtgi/mTs/bU+L PkRnRD4GtGqX7LjqGylCdy6cKO0B6hysyFch4DepCN84ckP/A6OH46XRR0B0UTxE/Qb9 gOjqXQlkXky7vRtRE77jbNSAFlar0/KV5fvlkNjEXlFbJttjMLICI2uuAA4ZGKwfhLIF HppQ== X-Forwarded-Encrypted: i=1; AJvYcCXOO6fMnpuqSxwfKQ7Jsc1UfOI0ZG0n0W2xLYUy0S2pyrMmupf3dogytwNVGzs1fz9GWSSRyRpO0FwXZo6FkOhy+3e4q27XSA== X-Gm-Message-State: AOJu0Yy+i/uVmCvhvG/VilADXUFwYyuBoiVU4LhN1IgoXycJqcU2Te7v dNOp95TK5zjQOF6RacwwmAsGvgDwIjrTDq099luDNVKhkAbARmld5JO4uQIlqRaouwZaPHBGNXI 3Qb+FXhth76e8P7XkMzsdwK/kMvM= X-Google-Smtp-Source: AGHT+IEgkzToSHATpZA18VZqAl8EHrVBlshZlO05AtfsPJCQfGCgxSbrPEReP7gdZI9Qw5VVU/HcLw9I1Mrj7VWPIHA= X-Received: by 2002:a17:90a:ec18:b0:2c9:a3ca:cc98 with SMTP id 98e67ed59e1d1-2d3924d5d0fmr1068308a91.7.1723483792838; Mon, 12 Aug 2024 10:29:52 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <3F5C5B7F-6EE5-437D-9E4A-4C86EC103E7A@getmailspring.com> In-Reply-To: Date: Tue, 13 Aug 2024 00:29:41 +0700 Message-ID: Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API To: Lanre Cc: John Coggeshall , Levi Morrison , PHP internals Content-Type: multipart/alternative; boundary="0000000000003f9722061f7fd720" From: pierre.php@gmail.com (Pierre Joye) --0000000000003f9722061f7fd720 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2024, 12:07=E2=80=AFAM Lanre wrote: > > > On Mon, Aug 12, 2024 at 10:50=E2=80=AFAM Pierre Joye wrote: > >> >> >> On Mon, Aug 12, 2024, 11:03=E2=80=AFPM John Coggeshall >> wrote: >> >>> >>> > I=E2=80=99m considering adding some C++ enhancements to the Zend API. >>> >>> >>> I would definitely like to see an RFC for this if it was to be >>> considered. To me, adding a whole new way of doing things internally >>> without completely removing the old way is just asking for a more britt= le, >>> potentially less secure, and harder to maintain codebase. The win of ma= king >>> it easier / "nicer" on a subset of developers who might prefer a C++ >>> interface isn't anywhere near worth the risk IMO. >>> >> >> >> if anything, I would rather go with rust (zig would have my preference >> ;-). The benefits would be to have a significant ease to contribute for >> many. >> >> Neither of c++ or rust would be easy to add. The later would have the >> huge advantage to bring a little bit more safety to the extensions APIs. >> >> A less diplomatic answer would be that c++ makes zero sense in 2024 for >> php (or any other language), a strong and bold take :) >> >> best, >> Pierre >> > > Lol it's been a long morning, thanks for the laugh. Look through php's > source code, do you see any mention of rust or zig? or any references to > their compilers? PHP already supports C++20 ( > https://github.com/php/php-src/blob/master/build/php_cxx_compile_stdcxx.m= 4) > and has at least one extension implemented in c++. > any of them won't happen anyway, being realistic. My point, while the last paragraph was slightly provocative, is as realistic as it can be. Adding thin layers to support external deps using c++ is a necessity and it is self contained without any other impact, and straightforward. Adding c++ to the engine,, or worst replacing it with c++, is non sense in 2024. If we were starting from scratch, why not, if the majority of the few contributors master it. But afaict it is not the case. Extensions/sapi are already being written using other languages than C (and a few in go) btw. Besides, long term, it brings direct support for many targets which are harder using c/c++, wasi/wasm f.e. (for a trendy one). side note, we did not see them in the kernel(s) (windows or linux) btw, and yet there are here. ps: I still know the code there, a bit ;-) best, Pierre > --0000000000003f9722061f7fd720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 13, 2024, 12:07=E2=80=AFAM Lanre = <lnearwaju@gmail.com> wrot= e:


On Mon, Aug 12, 2024 at 10:50=E2=80=AFAM Pierre Joye <pierre.php= @gmail.com> wrote:


On Mon, Aug 12, 2024, 11:03=E2=80=AFPM John= Coggeshall <john@coggeshall.org> wrote:

> I=E2=80= =99m considering adding some C++ enhancements to the Zend API.
<= /blockquote>
I would definitely like to see an RFC for this if it w= as to be considered. To me, adding a whole new way of doing things internal= ly without completely removing the old way is just asking for a more brittl= e, potentially less secure, and harder to maintain codebase. The win of mak= ing it easier / "nicer" on a subset of developers who might prefe= r a C++ interface isn't anywhere near worth the risk IMO.


if anything, I would rather go with rust (zig would have my= preference ;-). The benefits would be to have a significant ease to contri= bute for many.

Neither o= f c++ or rust would be easy to add. The later would have the huge advantage= to bring a little bit more safety to the extensions APIs.

A less diplomatic answer would be that c= ++ makes zero sense in 2024 for php (or any other language), a strong and b= old take :)

best,
<= div dir=3D"auto">Pierre

Lol it&= #39;s been a long morning, thanks for the laugh. Look through php's sou= rce code, do you see any mention of rust or zig? or any references to their= compilers? PHP already supports C++20 (https://github.com/php/php-src/blob/master/build/php_cxx_co= mpile_stdcxx.m4) and has at least one extension implemented in c++.=C2= =A0

any of them won't happen anyway, being realistic.<= div dir=3D"auto">
My point, while the last parag= raph was slightly provocative, is as realistic as it can be.

Adding thin layers to support externa= l deps using c++ is a necessity and it is self contained without any other = impact, and straightforward.

Adding c++ to the engine,, or worst replacing it with c++, is non sens= e in 2024.

If we were st= arting from scratch, why not, if the majority of the few contributors maste= r it. But afaict it is not the case.

Extensions/sapi are already being written using other language= s than C (and a few in go) btw.

Besides, long term, it brings direct support for many targets whi= ch are harder using c/c++, wasi/wasm f.e. (for a trendy one).

side note, we did not see them in the= =C2=A0 kernel(s) (windows or linux)=C2=A0 btw,=C2=A0 and yet there are here= .

ps: I still know the c= ode there, a bit=C2=A0 ;-)

best,
Pierre=C2=A0
--0000000000003f9722061f7fd720--