On Tue, May 27, 2025 at 9:41 PM Ben Ramsey wrote:
>
> Last night, I identified a need for `#[Deprecated]` on a userland class in
> one of my libraries, but I had to settle on `@deprecated` for the widest
> range of compatibility.
>
> Has there been anymore thought on putting together an implement
On Mon, May 12, 2025, at 8:57 PM, Larry Garfield wrote:
> I hereby open the vote on the Pipe operator RFC:
>
> https://wiki.php.net/rfc/pipe-operator-v3
>
> The vote will run until 26 May.
The vote is now closed. The final tally is 33 Yes to 7 No, or about 82%. The
RFC passes.
Thank you everyo
Am 27.05.2025 um 20:07 schrieb Levi Morrison:
To me, being able to turn off opcache defeats the purpose of putting it into
core. In fact, take this part of the RFC's introduction:
Part of this is, at least to me, that "turning off" OpCache is not a
binary things: bytecode caching on/off, bytec
Am 27.05.2025 um 18:47 schrieb Ben Ramsey:
Is this really a *need*, or is it more of a recommendation? If it's left
in a user's configuration, what is the impact?
A warning on startup:
PHP Warning: Failed loading Zend extension 'opcache.so' (tried: ...)
On 5/24/25 15:28, Niels Dossche wrote:
On 24/05/2025 21:24, Rob Landers wrote:
On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:
Hi
In my opinion, the return type should not be nullable.
Returning NULL when the platform (or PHP on that platform) doesn't support
getting this information i
Thanks Tim for the answer.
Your replies went to the Spam folder. I don't know why.
I'll change the template as you suggested as soon as possible.
On Tue, May 27, 2025 at 1:11 PM Tim Düsterhus wrote:
> Hi
>
> Am 2025-05-27 09:08, schrieb Dmitry Derepko:
> > As Tim said, it needs at least a 2 we
> On Jan 13, 2021, at 06:43, Benjamin Eberlei wrote:
>
> On Wed, Jan 13, 2021 at 1:05 PM Brent Roose wrote:
>
>> Hi Sara
>>
>>> On 22 Dec 2020, at 19:54, Sara Golemon wrote:
>>>
>>> On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas <
>>> nicolas.grekas+...@gmail.com> wrote:
>>>
It would
On 5/24/25 04:49, Rowan Tommins [IMSoP] wrote:
On 24 May 2025 10:08:46 BST, "马正强" wrote:
Hello internals,
I’d like to propose adding with as a full alias for the namespace-related
use keyword in PHP.
...
- Does this improvement warrant an RFC?
- Are there objections to the concept or
On Mon, May 26, 2025 at 4:49 AM Tim Düsterhus wrote:
>
> Please find the RFC including more details at:
> https://wiki.php.net/rfc/make_opcache_required
Quoting from the RFC:
> OPcache being a non-optional part of PHP and always being loaded does not
> mean that OPcache functionality is always a
On 5/27/25 12:01, Derick Rethans wrote:
On 27 May 2025 17:37:47 BST, Ben Ramsey wrote:
Are you suggesting that the function itself not be available or that it throws
when you attempt to call it on a system that doesn't support it?
I don't like the idea of the function not being available if
On 27 May 2025 17:37:47 BST, Ben Ramsey wrote:
>
>Are you suggesting that the function itself not be available or that it throws
>when you attempt to call it on a system that doesn't support it?
>
>I don't like the idea of the function not being available if the system
>doesn't support the funct
On 5/26/25 05:47, Tim Düsterhus wrote:
Hi
Arnaud, Ilija and I would like to propose making OPcache a non-optional
part of PHP starting with PHP 8.5.
Please find the RFC including more details at: https://wiki.php.net/rfc/
make_opcache_required
As of now OPcache cannot be statically compile
> Le 27 mai 2025 à 00:51, David CARLIER a écrit :
>
> Hi,
>
> Working through this https://github.com/php/php-src/pull/18651/files, do not
> mind waiting for PHP 9 if needs be. Let me know what you think.
>
> Cheers.
Hi,
Those functions are documented to return false on failure (e.g.
http
Hi
Am 2025-05-27 09:08, schrieb Dmitry Derepko:
As Tim said, it needs at least a 2 week discussion period.
Could you share the reference?
I already did in my email: https://wiki.php.net/rfc/howto (“When
discussion ends, and a minimum period of two weeks has passed”).
Here it is. I've add
Am 27.05.2025 um 10:00 schrieb Claude Pache :
>> Le 27 mai 2025 à 00:51, David CARLIER a écrit :
>> Working through this https://github.com/php/php-src/pull/18651/files, do not
>> mind waiting for PHP 9 if needs be. Let me know what you think.
>
>
> Those functions are documented to return fals
Le samedi 24 mai 2025, 19:42:34 heure d’été d’Europe centrale Niels Dossche a
écrit :
> In my opinion, the return type should not be nullable.
> Returning NULL when the platform (or PHP on that platform) doesn't support
> getting this information is an anti-pattern.
> Instead, availability of the
As Kamil mentioned, this is not limited to a single function but to
array type as a whole. See previous discussion
https://externals.io/message/116735.
On 5/24/2025 6:43 PM, 马正强 wrote:
I propose adding a |preserve_key_types| parameter to |array_keys()| to
address issues caused by automatic c
As Tim said, it needs at least a 2 week discussion period.
Could you share the reference?
Did I miss it or did I not see a PR linked from the RFC? While technically
having an implementation is not a prerequisite of an RFC, it is strongly
recommended. (Also, having written the original patch, I
On May 26, 2025, at 11:05 PM, tovilo.ilija wrote:
In the "Single-Expression functions in other languages" section, at
least the Rust and Swift examples are wrong, as such a syntax does not
exist for either of them. In case you got this info from an LLM, you
should always fact-check whatever an A
19 matches
Mail list logo
