at policy RFC then.
And to be clear: I'm favor of the “Casting out of range floats to int”
proposal from a technical point of view and I agree that it's a clearly
positive change. But I disagree that it is a “minor change” that doesn't
warrant the same treatment as any other RFC.
Best regards
Tim Düsterhus
. See sibling email.
Best regards
Tim Düsterhus
y new proposal
and as such requires 2 weeks of discussion. If you want to vote on this
RFC for PHP 8.5, you'll need to drop that section again.
Best regards
Tim Düsterhus
Hi
Am 2025-07-28 15:35, schrieb Tim Düsterhus:
Similarly to my other email: This is false. 2**53 is exactly
representable as float. Every power of two (<= 1024) is.
Small correction: That should've read `<= 1023` (or `< 1024`).
Best regards
Tim Düsterhus
ot;1e308"); // true
This is false. 1e308 is not exactly representable. The nearest
representable value is 1.1098e+308:
https://float.exposed/0x7fe1ccf385ebc8a0
Best regards
Tim Düsterhus
}
function runner() {
$jobId = 1;
try {
execute_job($jobId);
} catch (\Throwable $e) {
throw new MyJobHandlerException('Wrapping the exception',
$jobId, $e);
}
}
runner();
Best regards
Tim Düsterhus
description of your use case is very abstract,
can you provide a real-world example of a use-case you want to enable?
Best regards
Tim Düsterhus
: https://float.exposed/0x4350 and try incrementing or
decrementing the "Raw Decimal Integer Value".
Best regards
Tim Düsterhus
ot;, and 11 "Abstain", then Baz will have won as it has a clear majority of non-Abstain votes
cast.
That is quite verbose and requires two assumptions to be made, making it
hard to follow when not already knowing how STV works. I think it will
confuse more than it helps.
Best regards
Tim Düsterhus
Hi
On 6/25/25 10:05, Tim Düsterhus wrote:
voting just opened on the “Make OPcache a non-optional part of PHP”
RFC.
Please find the following resources:
- RFC: https://wiki.php.net/rfc/make_opcache_required
- Discussion: https://externals.io/message/127459
- PoC PR: https://github.com/php/php
... I think it would be f($a, $b, $e, $d, $f) ? Just raises
the effort to grok it even further.
Likewise `b` is specified twice.
Best regards
Tim Düsterhus
Hi
Am 2025-07-24 12:03, schrieb Tim Düsterhus:
I don't think they should. Specifically the (1) and (3) should not. My
expectation is that:
$f = foo(a: ?, b: 2, c: ?);
$f(1, 3); // calls foo(1, 2, 3);
and
$f = foo(c: ?, b: 2, a: ?);
$f(1, 3); // calls foo(3, 2, 1);
The
order of the
order parameters of the original function.
Best regards
Tim Düsterhus
erver
support that I specifically asked about is missing / broken.
In my email from July, 10th I also had some follow-up questions /
suggestions regarding the naming and the stack trace behavior, because I
believe the semantics that Arnaud described are confusing.
Best regards
Tim Düsterhus
. If you don't
see the value right now, but don't outright reject the proposal due to
being interested in future scope changes building on the proposal,
abstaining from the vote would probably be the right decision :-)
Best regards
Tim Düsterhus
re interpreted for an individual vote.
Best regards
Tim Düsterhus
RFC at this point:
https://wiki.php.net/rfc/destructuring_coalesce. Perhaps it might make
sense to revisit that one?
Best regards
Tim Düsterhus
learly is incomplete. Given the
complexity of the implementation, there is a significant risk that it
cannot be stabilized until hard freeze and that “amendments” to the RFC
will need to be made due to unexpected issues popping up during the
finalization of the implementation and review.
Best regards
Tim Düsterhus
e “all remaining arguments” must come between positional and
named parameters. It would make more sense to me for it to become last,
because it would also make it clearer that named parameters take
priority over `...`. Is there some technical limitation that caused this
choice to be made?
Best regards
Tim Düsterhus
ar) {
$var = $value;
};
}
$string = "Hello World!";
$string
|> strtolower(...)
|> ucfirst(...)
|> assign_to($result);
var_dump($result);
Best regards
Tim Düsterhus
cipate in the discussion, so I would expect a vote around end of
August at the earliest.
Best regards
Tim Düsterhus
[1] I'll be on vacation myself in August :-)
ade to the RFC since July, 9th.
This means the vast majority of the proposals have been unchanged for
roughly the last two weeks.
Therefore Gina plans to open the vote(s) on Friday (give or take).
Best regards
Tim Düsterhus
2 days ago) and making the previously
announced changes (i.e. the ones that Arnaud announced 20 days ago) to
the RFC text before claiming that the discussion has quieted down and
that the RFC is ready for a vote?
Best regards
Tim Düsterhus
elaborate why you decided to not vote “yes” for what
you asked for?
I don't think I did ask *for* set(). I said I didn't see (obvious)
problems with set(), in other words I said that I wasn't against it. See
also https://news-web.php.net/php.internals/128123.
Best regards
Tim Düsterhus
tee you even have the same object. At the end of the day, it is up
to the programmer building that system / program to provide those guarantees—
not the language.
I agree with both Eric's response to this paragraph.
Best regards
Tim Düsterhus
es.
I’d appreciate if voters could settle on a yes for “set only” for 8.5.
Wdyt? Would this help to get closer to closing the discussion?
From my side, removing the get hook part from the RFC would definitely
settle the discussion.
Best regards
Tim Düsterhus
#x27; hook is perceived complexity. It is not at all clear to me
why this means that we must now rush something with clear issues into
PHP 8.5.
Best regards
Tim Düsterhus
*behavior* is associated with them, for
properties there is not.
A 99% case is not sufficient for me to rely on when there's explicit
communication by the class author that I may rely on properties not
suddenly changing.
Best regards
Tim Düsterhus
isted since 4 PHP versions (in
case of readonly).
Best regards
Tim Düsterhus
o user expectations.
"Cached get" is just init with extra confusion.
Best regards
Tim Düsterhus
trivial to
implement.
I disagree on the "reasonable" part.
Best regards
Tim Düsterhus
the init hook will be called
when the backing store is uninitialized. The result of the init hook
will then also go through the get hook. On subsequent reads only the get
hook will be called.
Best regards
Tim Düsterhus
Best regards
Tim Düsterhus
),
};
}
}
Making `Foo` a plain old data class without any behavior after
construction and with very obvious control flow within the constructor.
This results in both more efficient and easier to reason about code.
Best regards
Tim Düsterhus
k-less.
As to the RFC text itself, I like how carefully the “RFC Impact” section
of the updated RFC template [1] has been filled in. I don't have any
other remarks, except LGTM :-)
Best regards
Tim Düsterhus
[1] https://externals.io/message/127834
te of
appreciation with regard to how well-written and well-researched your
first RFC was. Looking forward to see with what you come up in the
future :-)
Best regards
Tim Düsterhus
y positive that it would not change my mind regarding the
cost/benefit ratio of the proposal.
Best regards
Tim Düsterhus
source of truth (and contradicts your
response anways), unless explicitly specified in the RFC together with a
clearly specified revision.
Best regards
Tim Düsterhus
/static_variable_inheritance.
Best regards
Tim Düsterhus
Hi
Am 2025-07-14 13:54, schrieb Gina P. Banyard:
The purpose of this integer is to indicate what is the maximal integer
value that can be correctly represented by a float.
On 32 bits this is equal to PHP_INT_MAX, but on 64 bits it is
9007199254740991 (which is 2^(53) – 1) as the mantissa of a f
uthor of the original RFC, I agree that the situation
changed and adding support for #[\Override] on properties makes sense to
me (especially considering the simplicity of the implementation).
Best regards
Tim Düsterhus
Hi
Am 2025-07-02 18:23, schrieb Arnaud Le Blanc:
We will update the RFC, but here are a few answers:
I don't think this has happened yet.
On Wednesday, July 2nd, 2025 at 17:05, Tim Düsterhus
wrote:
How will PFA calls appear in a stack trace and how will PFA Closures
look like to `var
everybody's pace, though.
Each PHP version is supported for 4 years by the PHP project [1], thus
giving folks at least 4 years to handle each deprecation until they are
forced to upgrade to a supported PHP version.
Best regards
Tim Düsterhus
[1] And possibly even longer by the various
roperties, and that means even readonly classes/properties are
mutable, in
the generic case.
`readonly` guarantees the immutability of identity. While you can
certainly mutate mutable objects, the identity of the stored object
doesn't change.
Best regards
Tim Düsterhus
Hi
Am 2025-07-08 17:10, schrieb Larry Garfield:
The only way to make the readonliness fully guaranteed would be to
force a readonly property to be cached
Or by not allowing a `get` hook on readonly properties, of course.
Best regards
Tim Düsterhus
m/php/php-src/blob/677a1f80c86b7a5848985bf44714210d0b89900b/ext/spl/php_spl.c#L583-L590
That's an explicit special case in the language that could go away.
Best regards
Tim Düsterhus
really.
The behaviour may be weird, but notice that people won't do this by accident.
See above regarding "undocumented behavior". Also to my understanding
this is not about "preventing workarounds", but rather removing this
branch, which is just surprising behavior:
`zend_internal_attribute`? Would applying #[\DelayedTargetValidation] +
#[\Deprecated] on a regular class error or not?
Best regards
Tim Düsterhus
ed, use
header().
Best regards
Tim Düsterhus
On a first look, I agree that
`use`ing a trait is the single and obvious point where the message for a
deprecated trait should be emitted and can't think of anything else.
Best regards
Tim Düsterhus
ot why one would want to do so.
Best regards
Tim Düsterhus
nt $i) {
throw new \Exception();
}
$f = foo("abc", ?);
$f(123);
How will the stack trace look like? Does `#[\SensitiveParameter]` work
properly?
Best regards
Tim Düsterhus
was newly introduced).
Best regards
Tim Düsterhus
drop "Variant"
from the enum names? As they're namespaced, `Base32::Ascii` seems
fairly self-explanatory.
You probably meant s/Tim/Rowan/.
Best regards
Tim Düsterhus
e changes in-between.
Best regards
Tim Düsterhus
xt RFC) - which clearly is
undesirable.
Best regards
Tim Düsterhus
hat others expressed).
Alternatively `stripos()` would also work.
Best regards
Tim Düsterhus
be considered a “new extension” and must therefore follow the
Exception policy outlined in:
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables
Best regards
Tim Düsterhus
and `$foo(?)`
would be useful.
- Starting with the “RFC Impact” section, several sections of the
template are not filled in.
Best regards
Tim Düsterhus
Hi
Am 2025-06-11 09:38, schrieb Tim Düsterhus:
voting just opened on the “Make OPcache a non-optional part of PHP”
RFC.
Please find the following resources:
- RFC: https://wiki.php.net/rfc/make_opcache_required
- Discussion: https://externals.io/message/127459
- PoC PR: https://github.com
implementation - or at least a clear implementation plan - will go
nowhere. See also: Generics.
Best regards
Tim Düsterhus
It's mostly used when there are multiple equally-valid choices
(which I don't think is the case here). As the RFC author you are
expected to be the subject-matter expert and should make a decision that
is then voted on, rather than deciding every detail by an individual
vote.
Best regards
Tim Düsterhus
’t
believe should be in PHP or would not use ourselves would not make
sense.
Best regards
Tim Düsterhus
bject before
__clone() is called.
Both of these statements can describe user expectations, but each of
them justifies a different version of the RFC.
Best regards
Tim Düsterhus
thFoo($foo) {
if ($this->foo === $foo) {
return $this;
}
return clone($this, ['foo' => $foo]);
}
To make sure you are only creating a clone when actually changing
anything.
Best regards
Tim Düsterhus
/ the engien to possibly
optimize `\in_array()` into `match()` or similar when only a small
number of values need to be matched.
Best regards
Tim Düsterhus
majority is required. Voting ends 2025-06-25
08:00:00 UTC.
Best regards
Tim Düsterhus
probably
discuss this in more detail in the official RFC discussion thread.
Best regards
Tim Düsterhus
to GitHub is dead (probably due to the force-pushes), but the
tests in the current version of the PR resolved my question by
attempting to re-assign from within the class (such that visibility is
not the cause of the error).
Best regards
Tim Düsterhus
Hi
Am 2025-05-26 12:47, schrieb Tim Düsterhus:
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
Since there was not much of a discussion
icient design space for a “Future
Scope” solution (e.g. one that passes the $withProperties array to
`__clone()` or the original object - which would enable your WeakMap
use-case but is orthogonal to clone-with). I have just added that to the
“Future Scope” section:
https://wiki.php.net/rfc/clone_with_v2?do=diff&rev2%5B0%5D=1748959452&rev2%5B1%5D=1749034411&difftype=sidebyside
Best regards
Tim Düsterhus
s before the visibility check, which would
imply that the `readonly` doesn't have an effect: https://3v4l.org/nqgpL
Best regards
Tim Düsterhus
g. IDEs, static analyzers,
documentation, confusion regarding another closure syntax, …).
Best regards
Tim Düsterhus
s not logical as we have a top type that is not
actually a top type.
See my reply to your reply to Ilija.
Best regards
Tim Düsterhus
y the difference between a
“procedure” and a “function” [1]. That's why it makes sense to me to
treat `void` differently from the other types. See also: The `(void)`
cast which we decided to make a statement rather than an expression that
always evaluates to `null`.
Best regards
Tim Düs
type
hierarchy is the right choice and when considering “untyped returns” to
be soft-deprecated / discouraged, there are no inconsistencies either.
Best regards
Tim Düsterhus
Hi
Am 2025-05-13 14:03, schrieb Tim Düsterhus:
As with every RFC, a 2/3 majority is required. Voting ends 2025-05-27
at 12:30:00 UTC.
For some reason I thought the vote would have ended today instead of
yesterday. Anyways: The RFC was accepted with 25 (Yes) to 1 (No) vote
(96%), with one
. To explain further: The `opcache.so` will no longer exist, thus
the behavior is as with any other non-existent extension you are trying
to load.
You can already try yourself with `php
-dzend_extension=does-not-exist.so`
Best regards
Tim Düsterhus
better from there.
And of course there's also the benefits to the users of PHP, since less
configuration will be required for a production set-up. If OPcache is
always loaded, it means that it will also be enabled by default for FPM
set-ups, since `opcache.enable` defaults to `1`.
Best
nd you strictly following the
template and the “RFC How-To” to make sure that the RFC is complete and
follows proper process.
Best regards
Tim Düsterhus
probably be longer to give everyone
sufficient time to read the RFC and think it through.
Personally I did not yet have time to carefully read and understand the
RFC to provide proper feedback.
Best regards
Tim Düsterhus
clone-with behaves exactly like regular property
assignments. This means your example behaves like `$foo->{"\0Foo\0bar"}
= 123;` and thus will throw “Error: Cannot access property starting with
"\0"”. I have added a test to the implementation [1]. Adding that to the
RFC
binaries with OPcache enabled in the
first place (e.g. for use with FrankenPHP).
Best regards
Tim Düsterhus
creating a new
namespace and moving over the matching functions together with a
discussion of some namespace structure, including matching exceptions
(see https://wiki.php.net/rfc/extension_exceptions).
Best regards
Tim Düsterhus
logic to support the named parameters is purely
implemented in the parser. The actual function implementation is
provided to “round off” the implementation and because it was super
simple to add.
Best regards
Tim Düsterhus
the used syntax. If the second parameter would be a
regular array rather than using the named parameter syntax, making
clone() a function would not be necessary (but wouldn't make things
harder either).
Best regards
Tim Düsterhus
[1] As an example, with the currently proposed named par
king a array as
the second parameter would allow for the following, which might combine
the best of both worlds?
clone($obj, array(foo: 1, bar: "baz", object: "this is not
blocked"));
Best regards
Tim Düsterhus
ts numeric properties in objects and it
does not seem correct to make this an artificial limitation when the
behavior of numeric array keys follows the existing semantics (e.g. when
casting an array to an object).
Best regards
Tim Düsterhus
he
cloned object after it observed its value. This seems not to be
something relevant in practice, because why would the exact value of the
property only matter during cloning, but not at any other time?
Best regards
Tim Düsterhus
might want to update during cloning. The lack of “use cases” is the
primary reason we made the more conservative choice, but we are not
particularly attached to this specific behavior.
Best regards
Tim Düsterhus
es as $key => $value) {
$cloned->{$key} = $value;
}
return $cloned;
Just with the exception that writing readonly properties is allowed on
the clone (unless already touched by `__clone()`).
Best regards
Tim Düsterhus
e proposed policy.
Best regards
Tim Düsterhus
a bit too specific. Did you mean to also
include it in this policy?
That paragraph is intended as an example for my train of thought / how I
would interpret my suggested guidelines for hypothetical breaking
changes. Of course I do not expect anyone to propose an RFC to disallow
single-letter variables (not even in a major).
Best regards
Tim Düsterhus
detect, but break
almost every program, thus would be unacceptable.
Best regards
Tim Düsterhus
ll merge the PR making dynamic `assert()` a noop as a bugfix, though:
https://github.com/php/php-src/pull/18521#issuecomment-2869905393
Best regards
Tim Düsterhus
Hi
Am 2025-04-27 22:12, schrieb Tim Düsterhus:
as announced in the URI RFC discussion thread
(https://externals.io/message/123997#127142), I've now written up an
“Exception Hierarchy” policy RFC together with Gina.
Please find the following links:
RFC: https://wiki.php.ne
://github.com/php/php-src/pull/18521#pullrequestreview-2825782965
Best regards
Tim Düsterhus
is already implied by it being legal to add features
without an RFC, but would be good to spell out explicitly.
Best regards
Tim Düsterhus
ainst the benefit, but not a blocker
in itself.
Yes, even with the support for these pseudo-packages, every author would
need to remember to add those dependencies, which definitely has a cost
on the entire ecosystem.
Best regards
Tim Düsterhus
gt;foo = $value;
}
}
}
$f = new Foo();
$f->foo = 'dummy';
var_dump($f->foo);
Best regards
Tim Düsterhus
1 - 100 of 758 matches
Mail list logo
