e vote would be Major changes themselves, so
unless the changes happen right away and are then uncontentious, I would
expect the new vote to come no earlier than 3-4 weeks after the cancelation.
Best regards
Tim Düsterhus
on. The vote was then
canceled and later (successfully) restarted:
https://externals.io/message/127791#127803
Best regards
Tim Düsterhus
eeing that you updated the status
in the RFC, but not on the list. I'm doing that to properly wrap things up:
The RFC has been declined with 3 (Yes) to 28 (No) votes (10% acceptance)
and 4 Abstentions.
Best regards
Tim Düsterhus
Change” to the
RFC, the cooldown period resets to 14 days.
Best regards
Tim Düsterhus
il we have some helper (e.g. `**s**et_mangled_object_vars`). But
__sleep() can just go away.
Best regards
Tim Düsterhus
with deferring that
one until we have some helper (e.g. `**s**et_mangled_object_vars`).
But
__sleep() can just go away.
We've added a note in the "Future scope" section, phrased like this:
Consider dealing with __wakeup / __sleep separately as the impact
might
be specific to each one
Thank you.
Best regards
Tim Düsterhus
gic is available, but the old is not yet deprecated.
Best regards
Tim Düsterhus
nd G don't exist in Perl (it would be d<, d>, f<, and f>
respectively; these format specifiers could be deprecated if this RFC
ships).
Both w and W are already taken in Perl and would actually be a
difference.
Best regards
Tim Düsterhus
A better `pack()` with a streamlined format “description” would probably
fit with Ignace's proposed new Encoding extension:
https://externals.io/message/127716#127716
Best regards
Tim Düsterhus
etters” in question, look at the next character.
3. Different Design Philosophy
This is simply false. v/n/V/N identically exist in Perl. J is not clear
to me, and P appears to be different (but I don't do enough Perl to say
for certain).
Best regards
Tim Düsterhus
al itself, of course :-)
Best regards
Tim Düsterhus
etter indeed. Factually stating that
it just met the required majority (while stating the majority) is
something different than saying it a close vote, which leaves room for
ambiguity.
Best regards
Tim Düsterhus
and skipping destructors for objects where the unserialization
hook didn't successfully run. The forefathers definitely considered
possible edge cases that might lead to security issues.
Best regards
Tim Düsterhus
aving tests that
verify robustness even when facing untrusted inputs, because that's just
something that will happen in the real world, despite the documentation
advising against it.
Best regards
Tim Düsterhus
Hi
Am 2025-08-29 22:21, schrieb Tim Düsterhus:
Please find the RFC at:
https://wiki.php.net/rfc/rfc_discussion_and_vote
And the PR at: https://github.com/php/policies/pull/23
I've made some more (major) changes to the PR on Friday and earlier
today. Please find the changelog in th
se, the RFC author needs to accurately calculate the
end date still. Personally I just round to the next half hour to be well
over 2 weeks and to get a nice round time. I've seen others simply use
the next UTC midnight after 14 days.
Best regards
Tim Düsterhus
f it needs
a follow-up RFC, follow-up informal discussion, or "just do it, it's
fine." (All of the above should still be included in Errata, of
course.)
See above, I believe this is already sufficiently clear based on the
“Minor change” policy.
Best regards
Tim Düsterhus
a vote; claiming the cooldown started
from the original RFC.
I don't see how that would be possible even with an intentionally
“malicious” reading of the policy. The policy specifies that the
discussion period of an RFC starts with the official RFC discussion
thread matching the title of the RFC and linking the Wiki page. Thus any
existing discussion clearly is not applicable to a newly created RFC.
Best regards
Tim Düsterhus
no new (reasonable) discussions
or changes to the specification should happen.
I've already made the rename yesterday.
Best regards
Tim Düsterhus
passed, the violation is
considered to not have occurred (i.e. it should not be possible to void
a vote at day 13 of the voting period).
Best regards
Tim Düsterhus
Hi
Am 2025-08-29 22:21, schrieb Tim Düsterhus:
Please find the RFC at:
https://wiki.php.net/rfc/rfc_discussion_and_vote
And the PR at: https://github.com/php/policies/pull/23
I've just made another (major) update to the PR:
- Dropped the “Repeated Discussion” sentence, as announced
the vote starts say December 10 and ends January 10th for a total
of 31 days.
Alternatively just sending an email "This RFC is still alive, I'm just
waiting until after the holidays" would reset the 6-week period. The
goal really is to make sure that the discussion thread is sitting
somewhere near the top of the inbox and the policy therefore indicates
“any email”.
Best regards
Tim Düsterhus
Hi
Am 2025-09-02 15:08, schrieb Tim Düsterhus:
1) Reference of discussion in RFCs
When I try to look into the discussions of older RFCs to find out why
they ended up the way they did, it’s not easy. You hardly can find
them. This is because they are often not referenced in the RFC itself
days within their waking hours, making it more likely for
(significant) errors to sneak in.
Best regards
Tim Düsterhus
ome wiggle room to account for varying schedules and DST /
timezone changes?
- 2 days: 40 hours (1 full day + 16 hours)
- 1 week: 160 hours (7 full days + 16 hours)
- 2 weeks: 328 hours (13 full days + 16 hours)
Best regards
Tim Düsterhus
gree that having the diff
publicly available would be useful.
Best regards
Tim Düsterhus
ss trivial stuff is double-checked against the
implementation and possibly discussed with a co-author. Only after
having made all the changes and having proof-read them, they would then
be announced on the list in bulk, ready for the next round of discussion
and resetting the timer.
Best r
makes sense and
I'm happy to include this requirement as part of my current “Clarify
discussion and voting period rules” RFC. Would you mind sending another
email to the discussion thread of that one to have it all in a single
location: https://news-web.php.net/php.internals/128594?
Best regards
Tim Düsterhus
Hi
On 8/17/25 16:41, Tim Düsterhus wrote:
RFC: https://wiki.php.net/rfc/rfc_vote_abstain
Discussion: https://news-web.php.net/php.internals/128185
PR: https://news-web.php.net/php.internals/128185
As with every RFC, a 2/3 majority is required. Voting ends 2025-08-31 at
15:00:00 UTC.
The RFC
re to
incorporate them as appropriate.
I intend to dogfood the proposed policy during discussion and voting of
this RFC. Changes to the PR will be considered changes to the RFC text.
To spell it out explicitly: This email marks the official start of the
minimum discussion period of 2 weeks.
Best regards
Tim Düsterhus
nchmarks will answer that question.
Best regards
Tim Düsterhus
aster clamp() is actually going to be compared to alternative
solutions.
would add it if there is a strong interest, otherwise I'd rather stick to a
minimalist implementation (like seen in most languages where clamp() is
available.
Best regards
Tim Düsterhus
in one of the following versions).
Best regards
Tim Düsterhus
n the stubs, the stub
generator should first be extended to handle them, even if it does not
(yet) use the information and then it should be consistently applied to
the entirety of PHP's stdlib.
Best regards
Tim Düsterhus
ndary::ClosedOpen); //
0.999888978
Best regards
Tim Düsterhus
8601
strings in JSON APIs anyways)
- Large auto-increment IDs in mature applications
Same as snowflakes.
Hope I addressed your concerns.
I'm afraid not.
Best regards
Tim Düsterhus
see how having a function that safely coerces a string into an int,
returning null if coercion fails, basically intval() with better error
handling and taking only `string`s, could be useful, but that's not what
is being asked here.
Best regards
Tim Düsterhus
ularly
meaningful with regard to the real world and the JSON example is wrong
as outlined above.
Best regards
Tim Düsterhus
7;m seeing that some
folks already discussed the contents, but did you mean for the RFC
already being ready for discussion or are some parts still missing? If
it's ready you should update the status [1].
Best regards
Tim Düsterhus
[1] Strictly speaking it would also need a fresh mailing list
imply that they are in favor of removing existing
aliases. I consider both adding new aliases as well as removing aliases
to be disruptive and believe that the best action is “doing nothing” and
accepting this as another case of a historical decision that might not
have been made today.
Best regards
Tim Düsterhus
tensions in the same section
that mentions both the pecl tool
(https://www.php.net/manual/en/install.pecl.pear.php), as well as manual
phpize (https://www.php.net/manual/en/install.pecl.phpize.php). Adding a
PIE subsection to that makes sense to me.
Best regards
Tim Düsterhus
Hi
Am 2025-08-19 15:38, schrieb Tim Düsterhus:
bukka (bukka). That would be nice to do as part of the
"implementation" for
this... :)
I've sent a PR: https://github.com/php/web-wiki/pull/33
Changes are live.
Best regards
Tim Düsterhus
Hi
Am 2025-08-19 15:14, schrieb Jakub Zelenka:
bukka (bukka). That would be nice to do as part of the "implementation"
for
this... :)
I've sent a PR: https://github.com/php/web-wiki/pull/33
Best regards
Tim Düsterhus
ction.
and
For **adding new functions**, classes or keywords, here are some
possibilities to measure potential impact:
(highlighting mine)
Best regards
Tim Düsterhus
easiest
for you to create a “clamp function v2” RFC instead.
Best regards
Tim Düsterhus
x27;t quite follow.
Best regards
Tim Düsterhus
&rev2%5B1%5D=1755500397&difftype=sidebyside
Best regards
Tim Düsterhus
Hi
On 8/17/25 16:41, Tim Düsterhus wrote:
RFC: https://wiki.php.net/rfc/rfc_vote_abstain
Discussion: https://news-web.php.net/php.internals/128185
PR: https://news-web.php.net/php.internals/128185
Apparently my clipboard didn't work properly. The PR link should of
course be different
g such an option, it will be
considered an abstention. Please vote “Yes” if you are in favor of the
RFC :-)
Best regards
Tim Düsterhus
hread should be sufficient. We would need your Wiki username, though.
Best regards
Tim Düsterhus
;t expect it to require an
RFC, but if it does, I'd be happy to write it.
As implied above and also indicated by the changed labels on the PR: RFC
please.
Best regards
Tim Düsterhus
Hi
On 7/23/25 00:03, Tim Düsterhus wrote:
This message is intended to begin the official discussion period. While
it would be great to bring this policy into effect before any RFCs
targeting PHP 8.6, I'll make sure to monitor the (list) activity with
regard to folks being busy finalizing
ll call it verbose. The
bigger issue to me is that it doesn't really explain much when you are
not already familiar with STV. Wikipedia is in a much better position to
explain this than the policy document. I also expect STV votes to be
fairly rare, most RFCs do not even come with secondary votes in the
first place, because details are decided in the discussion.
Best regards
Tim Düsterhus
Best regards
Tim Düsterhus
either way and I've also
intentionally abstained from voting on this deprecation.
Best regards
Tim Düsterhus
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
1 - 100 of 813 matches
Mail list logo
