[DISCUSSION] C++ Enhancements in Zend API

I’m 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 brittle, potentially less
secure, and harder to maintain codebase. The win of making it easier /
"nicer" on a subset of developers who might prefer a C++ interface isn't
anywhere near worth the risk IMO.

You aren't making any sense. Why would we remove the old way? Or why should
that be a prerequisite to improving the current API? How are functions that
simply proxy the C API inherently 'more brittle, potentially less secure,
and harder to maintain'? You haven't even seen the code in question?

    TVal(const zval *other) : TVal() { ZVAL_COPY(this, other); }
    TVal(zend_long value) : TVal() { ZVAL_LONG(this, value); }
    TVal(int value) : TVal() { ZVAL_LONG(this, value); }
    TVal(size_t value) : TVal() { ZVAL_LONG(this, value); }
    TVal(bool value) : TVal() { ZVAL_BOOL(this, value); }
    TVal(std::string_view value) : TVal() { ZVAL_STRINGL(this,
value.data(), value.size()); }
    TVal(double value) : TVal() { ZVAL_DOUBLE(this, value); }
    TVal(const char *value) : TVal() { ZVAL_STRING(this, value); }
    TVal(const std::string &value) : TVal() { ZVAL_STRINGL(this,
value.c_str(), value.size()); }
    bool IsNull() const { return Z_TYPE_P(this) == IS_NULL; }
    bool IsTrue() const { return Z_TYPE_P(this) == IS_TRUE; }
    bool IsFalse() const { return Z_TYPE_P(this) == IS_FALSE; }
    bool IsBool() const { return Z_TYPE_P(this) == IS_TRUE ||
Z_TYPE_P(this) == IS_FALSE; }
    bool IsLong() const { return Z_TYPE_P(this) == IS_LONG; }
    bool IsDouble() const { return Z_TYPE_P(this) == IS_DOUBLE; }
    bool IsString() const { return Z_TYPE_P(this) == IS_STRING; }
    bool IsArray() const { return Z_TYPE_P(this) == IS_ARRAY; }
    bool IsObject() const { return Z_TYPE_P(this) == IS_OBJECT; }
    bool IsInstanceOf(zend_class_entry *ce) const {
        return Z_TYPE_P(this) == IS_OBJECT && (ce == Z_OBJCE_P(this) ||
instanceof_function(Z_OBJCE_P(this), ce));
    }
    bool IsCallable() const { return zend_is_callable((zval *) this, 0,
nullptr); }
    bool IsResource() const { return Z_TYPE_P(this) == IS_RESOURCE; }
    bool IsReference() const { return Z_ISREF_P(this); }

The above is a snippet from my current implementation, so please elaborate
on which part of that is so crazy to you.

Cheers,
Lanre.

I’m 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 brittle, potentially less
secure, and harder to maintain codebase. The win of making 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

On Mon, Aug 12, 2024 at 9:49 AM Levi Morrison levi.morrison@datadoghq.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.

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

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

On Aug 14, 2024, at 3:05 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I want to remind everyone on the thread that code does not only have to
be written, which is the "easy part", but it also has to be supported by
everyone into the future and chances that the original author sticks around
are not that high to do it.

The Rust thing is shitposting for the sake of shitposting and memeing on
the theme "rust solves everything" and "lets rewrite everything into Rust".
Here's a link with the reminder of the hard rules php-src and internals
have: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
And here's the wiki page on the internals etiquette:
https://wiki.php.net/email_etiquette_for_people_new_to_php_internals

PHP has C as core and has allowed C++ for extensions. Expanding that
support is a no-brainer, especially since modern C++ has stepped up in
major ways and I don't think C sees a lot of development any more, so it
makes sense to move towards C++.

IF there is a serious consideration given to evolving PHP to be written in
another language — vs. just a newer version of C — I think any reasonable
analysis would indicate that none of the languages proposed in this thread
would be appropriate; not Rust, not C++, and not Go. Why not?

Can you point out where either of us suggested writing PHP in another
language? You might be mixing this up with the C11 thread, which has
nothing to do with this. All I'm proposing is improving the current C++
support in the engine.
https://github.com/php/php-src/blob/master/Zend/zend_portability.h already
guarantees compatibility with c++ thanks to the BEGIN_EXTERN_C()
and END_EXTERN_C() macros defined right at the top and that are used all
around the engine. Notice how that macro compiles to nothing when C++ isn't
being used? I'm simply proposing more of those.

1. Rust is vastly different from C and re-writing in Rust would require
   basically rewriting everything from ground up. The scope of such as project
   would likely make the failed effort toward PHP6 even look quaint.

Yes, it is possible that one or a few individuals could on-their-own
devote 1-3 years to write PHP in Rust and then present to the community and
the community could accept it as the next version of PHP. However, AFAIK
there is no one individual or team who is currently or likely to do this,
and having the community accept their work is even less likely.

2. C++ is vastly more complicated to program in than C, and adopting C++
   would further narrow the number of people who are both proficient enough in
   both C++ and motivated enough to contribute to PHP's codebase. That would
   likely be just a handful of people today and with not much prospect for
   more in the future.

3. While I would love it if PHP were written in Go, I just do not see it
   happening because it would take a mostly full rewrite like with Rust and
   even as a Gopher I am not sure Go is the language I would pick to develop
   PHP in if there were no existing constrains in large part because of its
   inability to go low-level enough (pun intended), especially related to
   memory management.

However, there IS a language I think the PHP should seriously consider —
if we do seriously consider a new language at all— and that language is
Zig.

If you are not familiar with Zig — or have simply not explored it yet — I
would highly recommend reading at least the first article if not all of
them:

—
https://www.infoworld.com/article/2338081/meet-the-zig-programming-language.html
— https://ziglang.org/learn/why_zig_rust_d_cpp/
—
https://erik-engheim.medium.com/is-zig-the-long-awaited-c-replacement-c8eeace1e692
—
https://sourcegraph.com/blog/zig-programming-language-revisiting-design-approach

For those who can't be bothered to visit any of the links but will read
the rest of an email, here are pull quotes from the first article that are
relevant to why Zig should be considered as a successor to C for PHP. I
presented these quotes in order of relevance for PHP and not in order
presented in the article:

— "Zig sports a high degree of interoperability with C and C++. ... Zig
can compile C and C++. It also ships with libc libraries for many
platforms. It is able to build these without linking to external libc
libraries."

— "Zig attempts not only to supercede C with its own syntax, but actually
absorb C into itself as much as possible."

— "(Zig's developer) said “Zig is a better C/C++ compiler than other C/C++
compilers since it supports cross-compilation out of the box, among other
things. Zig can also trivially interoperate with C (you can import C header
files directly) and it is overall better than C at using C libraries,
thanks to a stronger type system and language features like defer.”

— "There is no malloc keyword like in C and C++. Instead, access to the
heap is handled explicitly in the standard library. When you need such a
feature, you pass in an Allocator object. This has the effect of clearly
denoting when memory is being engaged by libraries while abstracting how it
should be addressed. Instead, your client code determines what kind of
allocator is appropriate."

— "Making memory access an obvious library characteristic is meant to
avoid hidden allocations, which is a boon to resource-limited and real-time
environments. Memory is lifted out of the language syntax, where it can
appear anywhere, and its handling is made more explicit."

— "Zig also includes safety features for avoiding buffer overflows, and it
ships with a debug allocator that detects memory leaks."

— "Zig also includes a build tool.... Zig’s build tool works in a
cross-platform way and replaces tools like make and cmake."

— "Zig is being used to implement the Bun.js JavaScript runtime as an
alternative to Node.js. Bun’s creator Jarred Sumner told me “Zig is sort of
similar to writing C, but with better memory safety features in debug mode
and modern features like defer (sort of similar to Go’s) and arbitrary code
can be executed at compile time via comptime. It has very few keywords so
it’s a lot easier to learn than C++ or Rust.”

— "Kevin Lynagh, coming from a Rust background, wrote, “The language is so
small and consistent that after a few hours of study I was able to load
enough of it into my head to just do my work.” Nathan Craddock, a C
developer, echoed the sentiment. Programmers seem to really like the
focused quality of Zig’s syntax."

============

Given that Zig was designed to and can compile C and C++ code directly,
"moving to" Zig would likely be almost trivial, at least the swapping out
the C compiler for the Zig compiler part. Then the maintainers of PHP could
decide which Zig languages features to use and where. Over time PHP's
maintainers could choose to evolve the PHP codebase to using more Zig
features over time (or not), features such as comptime code generation
that is built into the Zig language.

Zig's allocator memory model would also likely be a boon to PHP by giving
PHP more control about how and when to allocate memory for PHP programs.

Using the Zig build tool could also likely make it easier for someone new
to PHP core/extension development to getting a build working on their
machine for local development.

All of this is moot, it would be a huge investment and a whole other
discussion to port PHP to another language. That has nothing to do with my
proposal.

And finally, one other (IMO) HUGE benefit of switching to Zig would be
that it would likely be easier for new people to onboard to contributing to
the PHP codebase than if PHP sticks with C or especially if PHP were to
instead move to C++. I know Zig would make it easier for me to contribute.

#jmtcw

-Mike

P.S. One of my goals in the mid-term is to become proficient enough to
work in C on the PHP code base so I could write an extension and/or
contribute a patch to PHP for a passed RFC.

However, if PHP embraces C++ I will drop that goal because I know enough
about C++ to know about that I to become proficient in contributing to PHP
if it required be programming in C++ would need to become a full time C++
developer, which is not going to happen. So if you move to C++ then I give
up.

Again, I will reiterate that these proposed changes will not affect the
current course of PHP. Development will go on as usual and any bugs
introduced by this proposal will be contained to C++ extensions interacting
with the code. C devs can act like this doesn't even exist because as far
as the C compiler is concerned, it doesn't. On the other hand C++ devs
won't have to keep reinventing the wheel whenever they have to build an
extension with C++. What is a php extension if not a wrapper for a C/C++
lib?

That said, me giving up will be no skin off anyone's nose in the PHP
community. But it is very likely my giving up would just be the canary
dying in the coal mine indicating that many others will give up too, and
many more will never even try.

IOW, if you care about being able to have enough people to maintain PHP
into the future, you should really think hard before deciding to more PHP
to C++ development. And before you say there are lots of C++ developers,
consider that most good C++ would never even consider working on PHP as
they likely do not consider it a language worthy of their time.

IF I wanted PHP to be implemented in C++, I would simply fork it. How many
thousand RFCs do you think it will take to get anything reasonable done?
I'm baffled that I actually have to convince y'all to IMPROVE the current
support for C++, but calm down, no one wants you to quit.

Cheers,
Lanre.