My vote is on straight to ValueError without RFC. Deprecations should
only be limited to meaningful changes in functionality, not fixing
bugs or undefined behaviour. Lack of argument validation is not a
behaviour users would have relied on in past.
On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote:
> Hello everyone,
>
> I’d like to align on the approach to validating arguments for built-in
> functions (usually for flag inputs). Some ongoing discussions in PRs:
> - https://github.com/php/php-src/pull/15647
> - https://github.com/php/php-sr
On Mon, Mar 10, 2025, at 20:05, Daniel Scherzer wrote:
> Hi internals,
>
> I'd like to start discussion on a new RFC about allowing `never` for
> parameter types when declaring a method.
>
> * RFC: https://wiki.php.net/rfc/never-parameters-v2
> * Implementation: https://github.com/php/php-src/pu
On Mon, Mar 10, 2025, at 15:43, Ilija Tovilo wrote:
> Hi Rob
>
> On Mon, Mar 10, 2025 at 9:23 AM Rob Landers wrote:
> >
> > I’ve been trying to chase down a very subtle bug in 8.4 that only happens
> > when OPcache is enabled (I'm trying to create a reproducer to file an
> > actual bug). From w
Hi Gina,
1.
> The paragraph in at the beginning of the RFC in the > Relevant URI
> specifications > WHATWG URL section seems to be incomplete.
>
Hopefully it's good now. Although I know this section doesn't include much
information.
2.
> I don't really understand how the UninitializedUriExceptio
Hi Juris and Tim,
> Am 2025-02-23 18:47, schrieb Juris Evertovskis:
> > As those are URI validation errors, maybe something like
> > `Uri\WhatWg\ValidationError` would be both less clashy and less
> > redundant?
>
> I like that suggestion.
>
> Best regards
> Tim Düsterhus
>
I liked it as well, s
Hello everyone,
I’d like to align on the approach to validating arguments for built-in
functions (usually for flag inputs). Some ongoing discussions in PRs:
- https://github.com/php/php-src/pull/15647
- https://github.com/php/php-src/pull/15883
- https://github.com/php/php-src/pull/17859
In some
Assuming that the variable gets created in the scope of the function
and that it never leaks outside of the scope (e.g. by reference), then
you can consider these things:
PHP will destroy the object when there are no more references to it in
the running script[1]. So, if the PDO object is limited
Hello, folks. If this is not the correct place to ask, I apologize.
> TL;DR: Does setting a variable to `null` (or even `unset`ing it) have **any**
> effect if that's the last instruction of a function?
The full version of the question with context:
I have a question about the inner workings of
On Mon, Mar 10, 2025, at 5:51 PM, Máté Kocsis wrote:
> I'm sure that people will find their use-cases to subclass all these
> new classes, including the WHATWG implementation. As Nicolas mentioned,
> his main use-case is minly adding convenience and new factory methods
> that don't specifically
Hello internals,
I’ve been trying to chase down a very subtle bug in 8.4 that only happens when
OPcache is enabled (I'm trying to create a reproducer to file an actual bug).
From what I can tell, OPcache doesn’t zero out cache slots, so occasionally, a
cache slot will contain garbage that happe
>function par_map(iterable $it, callable $c) {
> $result = [];
> async {
>foreach ($it as $val) {
> $result[] = $c($val);
>}
> }
>return $result;
>}
If the assumption is that each call can be asynchronous and all elements
need to be processed, the only proper tool is a concurrent i
>
> As noted, I am in broad agreement with the previously linked article on
"playpens" (even if I hate that name), that the "go style model" is too
analogous to goto statements.
>
The syntax and logic you describe are very close to Kotlin's implementation.
I would say that Kotlin is probably the
>
> Sure:
>
Yeah, this is a Watcher, a periodic function that is called to clean up or
check something. Yes, it’s a very specific pattern. And of course, the
Watcher belongs to the service. If the service is destroyed, the Watcher
should also be stopped.
In the context of this RFC, it's better t
On 10 March 2025 16:15:16 GMT, Vinicius Dias wrote:
>Hello, folks. If this is not the correct place to ask, I apologize.
>
>> TL;DR: Does setting a variable to `null` (or even `unset`ing it) have
>> **any** effect if that's the last instruction of a function?
>
>The full version of the question w
Hi Daniel,
> On Mar 11, 2025, at 08:05, Daniel Scherzer
> wrote:
>
> Hi internals,
>
> I'd like to start discussion on a new RFC about allowing `never` for
> parameter types when declaring a method.
>
> * RFC: https://wiki.php.net/rfc/never-parameters-v2
> * Implementation: https://github.co
Hi Vinicius
On Mon, Mar 10, 2025 at 5:15 PM Vinicius Dias wrote:
>
> > TL;DR: Does setting a variable to `null` (or even `unset`ing it) have
> > **any** effect if that's the last instruction of a function?
As others have pointed out, it is _almost_ completely unobservable.
There are two small d
> Let me summarize the current state for today:
>
> I am abandoning startScheduler and the idea of preserving backward
> compatibility with await_all or anything else in that category. The scheduler
> will be initialized implicitly, and this does not concern user-land.
> Consequently, the spaw
18 matches
Mail list logo
