On Tue, Aug 13, 2024, 12:07 AM Lanre <[email protected]> wrote:
>
>
> On Mon, Aug 12, 2024 at 10:50 AM Pierre Joye <[email protected]> wrote:
>
>>
>>
>> On Mon, Aug 12, 2024, 11:03 PM John Coggeshall <[email protected]>
>> wrote:
>>
>>>
>>> > 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
>>
>
> 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.m4)
> 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
>