On Thu 31 Jul 2025, 11:32 Lynn, wrote:
>
> When I read `catch (Foo);` I read the intention of it being on purpose,
> whereas `catch (Foo) {}` I can easily interpret as "the developer forgot to
> handle the error" or "I can't tell if this is a bug or not". This often
> requires something like:
> `
> Warning: non-representable float was cast to int
Will this have a significant performance impact?
> Warning: Cannot access offset of type TYPE on string
Why is this a warning and not a TypeError? If the goal is to make the
behavior identical to null coalesce operator then having a warning seem
On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote:
>
> On Mon, Jul 28, 2025 at 3:26 PM Rob Landers wrote:
>
>>
>> Wouldn’t a better approach be to allow serializing/deserializing
>> exceptions?
>>
>> — Rob
>>
>
> It would look like another workaround to my case. Same as deserializing
> data into a
>
> This would prevent most of the
vulnerabilities found in the dataset and we cannot think of a valid use
case for allowing this behavior
But not all. This function is dangerous on its own. Attack vectors are 99%
through superglobals but could come from other sources too. However, this
functio
On Fri, Jul 4, 2025, 16:50 fennic log wrote:
> This is basically an idea I have for PHP to support a main entry point.
> Where regardless of execution, if you run a PHP file, in CLI or Web
> request.
> If the file that is executed contains a main function, that is
> automatically executed by the
On Wed, Jul 2, 2025, 21:58 Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to
> add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
> year
What exactly is the context in which symfony uses it?
While I understand that dd is a valid way of debugging PHP code, I don't
think we should encourage this. Users should be encouraged to learn how to
use proper debugger like XDebug. Plus PHP has plenty of dumping functions
already and I see no need for yet another one.
If you use 32bit version of PHP then of course you will run into this
problem. But 32bit versions are used infrequently now, and this is a
known limitation. As far as I know, these functions have no issues
with year 2038 in 64bit. My point is that these functions work fine
and the fact that 32bit i
Why do you say that these functions do not work with year 2038?
https://3v4l.org/61VLh
I wouldn't be opposed to deprecating them, but I don't know if we have
a good enough reason to do so.
The RFC mentions that this will now become valid:
function foo(): void {
return null;
}
But what about the opposite:
function foo(): null {
return;
}
or what Larry was trying to suggest:
function foo(): null {
print 'test';
}
$val = foo();
As I understand, it was a conscious decision not to add this function
when str_contains was created. The reason is that case sensitivity is
locale-dependent, and for such use cases, mbstring extension is better
[1] & [2]. Do you think that locale is a concern here, and if not,
why? Would it be a go
As far as I know, this is how array keys are designed and changing
array_keys wouldn't solve the problem. The key is converted to the
appropriate type during creation. Array keys are defined as string|int
and expecting the values to be either string or int is a programming
error. Static analysis to
On Wed, 30 Apr 2025 at 21:13, Larry Garfield wrote:
> >> […] just that it's the only time I've seen $code used in the wild...
> >>
> >
> > PDO (for better or worse) also uses the `$code` for the error code
> > returned by the database. Unfortunately it also widens the (untyped)
> > $code from int
>Do you have a wording suggestion to make it clearer what is meant by
that sentence?
How about this:
The exception message MUST NOT be the only means of distinguishing
exceptions. Any two exceptions with different messages MUST be
identifiable either by a unique exception class name or code.
>The exception message MUST NOT be the only property that allows to
differentiate different types of error that the user may be interested in.
What does this mean exactly? Can you give an example?
>This discussion seems to have overlooked that the setting doesn't just
restrict the *display* of arguments, it restricts the *collection* of
those arguments into the Exception object, which has visible effects on
the behaviour and performance of the program.
Oh, I didn't know that. I assumed the
Thanks for sharing it.
This begins to look a lot like the nasty overloaded
PDOStatement::fetchAll. It would also be nice to have fetch_all for a
single column, and then we have it. I'd rather we avoid that if we
want to expand mysqli functionalities. How about adding
mysqli_fetch_all_object? No ne
> In an ideal world they are never revealed to the end user, but
real-world solutions fall short. It's not uncommon for people to have
display_errors enabled for some reason or another. It is also possible
for sites to be misconfigured, or for applications to make mistakes
and accidentally dump sta
I can't find any information on why this setting was introduced. I
guess that it was either to protect sensitive information or to reduce
verbosity in the logs, but either one seems like a poor reason for
this setting to exist. The INI comment seems to suggest that it was
introduced to protect sens
On Sun, 23 Mar 2025 at 12:52, Robert Chapin wrote:
>
> Hi PHP folks,
>
> I submitted a proposal on Monday that received no replies. The idea was
> about adding a functional construct nullc() that could act as an inline
> null coalesce for a variable. That task is currently not possible in a
> nu
Hi Kayck,
Thanks for your proposal. Here are some points from me:
empty() is not a function, it's a language construct that's a shorthand for
!isset($var) || $var == false.
While it has its uses empty() should be avoided whenever possible. It's
generally a sign of the programmer being lazy not d
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.
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
Hi,
Could you share the implementation?
Regards,
Kamil
I have no issue with adding more functions to the OpenSSL extension,
but they need to be very clearly documented and have an obvious API.
Cryptic names such as $pk or $sk cannot be used. While I really hate
array return types, if you must use it then it must be clearly
documented. It cannot just be
Hi Tim and Volker,
I'd be honest, I have a very negative attitude towards this proposal
and I'd be voting against it. It seems to me like it's creating a
problem and then trying to find a solution for it.
A return value is always supposed to be used. If some API is returning
a value that can be s
On Sun, 9 Feb 2025 at 20:58, Rob Landers wrote:
> I fully agree with you, however it is also the default password hashing
> algorithm. People may not read the docs and assume a generic implementation
> that isn’t constrained. Since it is the default and has constraints, we
> should probably at
Hi,
I would say that this is a pretty bad idea. 72 bytes of entropy are
quite a lot for *PASSWORDS*. Even if some users use a pass phrase
longer than that, the first 72 bytes are enough to provide sufficient
security. People who use it for other stuff, like in the linked
article, are only to blame
While the filter API wasn't designed with this in mind, the use of
filter_input to get the unmodified data is probably the only good
reason to ever use this API. If possible, it would be better to have
dedicated functions in standard for reading the unmodified input data
and then deprecate this fun
It sounds like a nice QOL improvement. I'm ok with preg_match not
working and I would even say it would be wrong if it did work like
that.
It would also prevent people from accidentally forgetting to provide
the matching subject in as it would generate UnhandledMatchError with
non-bool types.
I do
Hi Gina,
Your proposal makes sense to me. I agree that the behaviour should be
consistent.
If I understand correctly, an associative array currently binds only
to positional arguments. If you make this change, how will it interact
with PDO::FETCH_PROPS_LATE? Am I correct in assuming that this will
x27;t a very good discussion starter, so I imagine you
won't get many replies. I hope my explanation and the link to Stack
Overflow will help you in your current situation. I also encourage you
to read the mailing list rules if you haven't done so already:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
Regards,
Kamil Tekiela
Hi Theodore,
Do you know why the two exist? Was there any historical reason for this?
>From what cmb69 said[1], it seems like it may exist because of the
implicit semicolon in ?>, and after I tested it, it seems to be true.
Was there ever any other reason?
[1]: https://github.com/php/php-src/iss
They should have been deprecated back then. No RFC needed.
I have to admit I understood nothing from your email, but I got
curious about some of your words.
> A readonly property is two functionalities in one: write-once and
private set.
What do you mean it is private set? Readonly only means the property
is writable once. It does not affect its visibili
I've voted to deprecate based on my understanding that either passing
a non-empty string or relying on the default value would trigger a
deprecation. It wouldn't make sense for me to only deprecate passing
an explicit argument.
I agree that the path forward has not been made clear in the RFC. Will
Having constant parameters would be a tremendous help in refactoring old
code. I would love having local constants.
On Sun, Jul 28, 2024, 08:42 Rowan Tommins [IMSoP]
wrote:
>
>
> On 27 July 2024 23:14:32 BST, Morgan wrote:
>
> >Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions
> for both, and then when SHA4 comes along (as it inevitably will) another
> standalone function for one of its
Boolean is a much more confusing value here. A bit mask is ok, but I would
prefer a better solution. Maybe a simple value object?
I have added one more deprecation
Deprecate the second parameter to mysqli_store_result().
On Thu, 27 Jun 2024 at 05:57, Gina P. Banyard wrote:
>
> On Wednesday, 26 June 2024 at 14:54, Kamil Tekiela
> wrote:
>
> > I think the "Deprecate passing E_USER_ERROR to trigger_error()" should
> > be better explained. Why is using this constant a problem?
I think the "Deprecate passing E_USER_ERROR to trigger_error()" should
be better explained. Why is using this constant a problem? There is a
link to another RFC, but I can't see an explanation as to why
E_USER_ERROR suffers the same problem as fatal errors do. From an
average Joe's perspective, it
I see absolutely no reason to do this. There is no difference between
MySQL and MariaDB in terms of PDO. Sure, the actual RDBMSs have
differences, but they play no role when it comes to PDO.
If MariaDB decides to change the protocol some day then we would need
a new driver to replace mysqlnd. Only
Hi All,
The voting has ended. RFC was accepted unanimously with 29 votes.
Regards,
Kamil
I think the question here was more about what the syntax will be after the
parameters are substituted. But if I recall correctly, the quoting is done
by PDO:: quote so the syntax will remain the same. Only the buggy behavior
would be fixed when it comes to recognizing parameters.
Hi Internals,
I have opened the vote on https://wiki.php.net/rfc/deprecate-get-post-sessions
It will close on 2024-04-23
Regards,
Kamil
>1. In session_start(), it is possible to override ini settings like that:
>
>```php
>session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1',
>'referer_check' => '' ]);
>```
>
>The relevant options should also be deprecated in that context.
Yes, they are. You can see that in my draft PR
Hi Pablo,
Interesting proposal, but immediately I have two questions:
1. Why is passing extra arguments a problem at all? Is generating a
warning a good idea? If you would like to introduce a new syntax to
enforce non-variadic functions, shouldn't it be a runtime error then?
Generating a warning m
If there are no more comments, I would like to put this RFC to vote in
the next two days.
Hi Everyone,
Upon consideration of your comments, I have decided to adjust my RFC.
Please see the updated version
https://wiki.php.net/rfc/deprecate-get-post-sessions
Changes include:
- session.use_cookies will not be deprecated
- session.trans_sid_tags, session.trans_sid_hosts,
session.referer_c
-- Forwarded message -
From: Anton Smirnov
Date: Sun, 3 Mar 2024 at 19:56
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
To: Kamil Tekiela
Greetings!
I'm sorry for addressing you directly, if you can forward this message
to internals I'd be gr
Hi Anton,
> As I know some session-related middlewares force custom-only session_id
> handling by setting
>
>use_cookies = Off
>use_only_cookies = On
>
> and then using session_id(...) directly
>
> Example:
> https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137
I
this RFC is to reduce potential
security pitfalls.
Regards,
Kamil Tekiela
I love it!
When is CurlMultiException and CurlShareException thrown? I feel like
this part in general is not very clear in the RFC.
Hi Saki,
Why does this have to be done in PHP? Why can this not be done in SQL?
Also, I am not sure that mysqli implements this properly. It's
probably not the best extension to take an example of.
Regards,
Kamil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
Sorry, my bad. I thought the vote started 2 weeks ago.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
I think it might be even better to extend it by 2 weeks. It looks like
people were unaware that the voting has started on this RFC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
FWIW I think one year is more than enough of deprecation time for any
change, especially for something so easy as this. It's not like we are
forcing users to upgrade to the newest version as soon as possible. I
still haven't used PHP 8.3, and I most likely will not use it for
another year. In pract
I fully support this. I even wanted to propose this RFC myself. Implicitly
nullable parameters are extremely confusing in PHP 8 and they are very easy
to replace.
What should users replace $bucket property with in PHP 8.4? Is there
an alternative or is this a deprecation without a way to solve it? If
there is currently no alternative I would not deprecate it. Just
remove it once it becomes useless.
--
PHP Internals - PHP Runtime Development Mailing List
To
I have voted no. Not because I disagree with the proposal, but because
I think the timeline is wrong. First, we should identify a way to
deprecate and disable the option of naming anonymous classes. I
suggest we deprecate this "feature" in PHP 8.4 and remove it in PHP
9.0, as well as making the ano
Hi Máté,
I have one question. If the primary stream resources get the
is_resource hack, what hampers the changes from landing in a minor
version? I'd assume that the migration would be mostly seamless. Is it
the get_resource_type checks? Is it because is_resource also checks
whether the resource i
I don't know if this was designed this way purposefully, but it makes
sense to me. I see nothing out of the ordinary here. It makes for some
really nasty code, but that can probably be said about all code that
uses references.
If we try to simplify your example, we can see more clearly what's
happ
> Convert your PHP source files to UTF-8.
If the solution is as easy as just converting the encoding of the
source file, then why did we even need to have this setting at all?
Why did PHP parser support encodings that demanded the introduction of
this declare?
--
PHP Internals - PHP Runtime Deve
Hi Hans,
Can you share a little more details about how this works? This is a
pretty niche functionality, so most people probably don't know what it
is, how it works, or why it should no longer be used. Also, as Claude
mentioned, what is the preferred alternative?
Regards,
Kamil
--
PHP Internals
A class with a private constructor can still be instantiated. A class that
cannot be instantiated is pretty much useless. A static class would be just
a collection of functions. And I know that many developers write such
classes but it doesn't mean the language should encourage it. After all, if
so
You must enable bleeding edge.
Hi Craig,
Don't get me wrong, but I have a feeling you still didn't understand fully
my first message.
That's what I thought, but for some reason, casting null is deprecated only
> when it's provided as an argument to functions, all other cases it's
> fine... weird right?
>
No, passing null to n
I don't think that would actually be wise. Automatic casting of null to
other types is a handy feature and deprecating it brings no benefit to
anyone.
Instead, if you want, submit a proposal to reverse the direction. Make it
so that null is cast to an appropriate type in params and return values.
Hi Alessandro,
I would still advise to just let this empty() construct die a natural
death.
If you want to change anything, you must remember that it's basically a
syntactic sugar for `@!$var`
For example if(empty($var)) is just if(@!$var)
To change this function would require changing the rule
I would be voting against any function that checks for "empty". The
`empty()` construct we have now should almost never be used in any
reasonable code. It should be avoided at all cost. For this reason, I
see no need to introduce a new variant of the same thing. I also don't
believe there is any ne
Hi,
I don't understand what you are proposing and what problem you are trying
to fix. The RFC is not explaining things well.
A code like this already throws a fatal error.
function enc(string $a){}
enc(null);
The only thing remaining to be fixed in PHP 9 is to make this error
consistent on all function invocations.
> I didn't realise the payment gateway doesn't always provide the order
reference
Well, there you go. T
ld not consider the async feature of mysqli useful or
even a good reason to abandon PDO. IMHO the async feature is a failed
experiment with limited applicability.
Regards,
Kamil Tekiela
Yes, BCrypt uses only the first 72 bytes for hash generation. You can
test it with:
var_dump(password_verify(str_repeat('a', 72).'sdfsdf',
password_hash(str_repeat('a', 80), PASSWORD_BCRYPT)));
But I would not consider this an issue. Users rarely create passwords
longer than 72 bytes. 72 bytes is
>Do you think there is still demand for such error mode control features?
>
>Personally, I've never seen anyone prefer silent mode, so I think it's worth
>making the drastic change.
This may be right. There isn't a demand for this in **new** code and I
doubt anyone would come forward with a reaso
Hi Internals,
This is in relation to PR #10419: https://github.com/php/php-src/pull/10419
I was hoping to get it merged into PHP 8.3, but there were some
objections. I would like to receive some opinions from the broader
community.
According to the MySQL standard mysql_stmt_data_seek should be a
Can we align it to be the same as https://www.php.net/favicon.ico?v=2 ?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi Vinicius,
What would be the reason to add this? A reason cannot just be that there is
no such function. You can easily do it with a loop like you have just
shown. There isn't really any other way unless we introduce some driver
specific SQL builder. So what would we gain from it? Is it speed, s
I am not sure if others agree but in my opinion, Global Mersenne Twister
should have been a separate RFC. It has a discussion point that people
might want to discuss on mailing list first.
Hi Máté,
I agree with this proposal, and I will be voting yes. The function
overloads are not a big issue for PHP developers, and some are very
much in use, but the reasons you listed are convincing and the manner
in which you propose to do it should create an easy upgrade path.
I think one year
I love this idea. Although GitHub is not perfect, it would be so much
better than a mailing list. Mailings lists are annoying: they have very
poor searching capabilities, you can't unsubscribe from a thread you are
not interested in, you can't follow the conversation easily because it's
not always
>
> We have the special constants like \MyNamespace\MyClass::class. Would
> you envisage (or is there value in) equivalent constants like
> \MyNamespace\MyFunction::function?
>
If anything, I would suggest renaming the existing constant to something
more meaningful. There is no point in adding ::f
On Mon, Apr 10, 2023, 04:17 Deleu wrote:
>
> Or maybe when you wrote "Even if nothing would change in PHP 8" you meant
> something different than what I interpreted?
>
I meant things like refactoring, fixing bugs, updating dependencies.
Changes in code unrelated to changes in the language. When
> But what's the point of starting a greenfield project in PHP while
Typescript is right there?
If that is true then we have pushed PHP to its death. PHP is dead and we
can move on to other projects. But that's obviously not true. I could claim
the complete opposite: why start a project in Typesc
ery year when PHP releases a new
version, go over the changelog and make an effort to learn and use new
features. Even if your production is 3 years behind, you can try these out
in your development environment.
PHP will move forward and add new features, but sometimes it must also
break some things to move forward.
Kind Regards,
Kamil Tekiela
>
> I've changed the behaviour to throw a ValueError if a negative step is
> provided with increasing range and accept negative steps for decreasing
> ranges.
>
I am not sure this is better. This would introduce a BC break because now
it's not as easy to avoid the error as you can't just wrap the
Hi Hamza,
If you encounter a bug, please create a GitHub issue with reproducible
steps. Your description of a program crashing is not actionable, as we
cannot reproduce this error.
Regarding your second point, how do you want this to work? $names is just a
collection of string parameters. It's no
Hi Max,
On Thu, 9 Feb 2023 at 16:05, Max Kellermann wrote:
> - Jan 19 7:49 PM: commit
> https://github.com/php/php-src/commit/0df92d218e88a0 pushed to
> php-src
>
> Look how the commit is exactly a revert of the timelib PR that Derick
> Rethans closed and locked just the day before.
>
Ahh
> But because of the typed properties, you have to initialize them before
you
can access them. I think that is cluttering up the code.
It's not cluttering code. You don't need isset if you do it properly. You
have a bug if your code tries to access an uninitialized property.
> From a programmer's
Hi Lydia,
I understand where you are coming from because I encountered this a few
times myself, but every time it was actually because I was doing something
wrong. The reason for this limitation is actually very simple and logical.
Let me explain.
When you use untyped properties, the type is not r
Hi Sergii,
First of all, let me say that I am glad more people are willing to give
back to the PHP language. I'm happy you decided to join the ML.
However, the change you are proposing is unlikely to be well-received. PHP
already has too many functions. It is known as a kitchen sink[1].
I don't t
I don't think it's such a huge issue as you make it to be. The
documentation states this only as an alternative:
https://phpspreadsheet.readthedocs.io/en/latest/topics/accessing-cells/#looping-through-cells-using-indexes
It also mentions the pitfalls. I doubt many users would prefer that
"alternat
I am in both camps. I think some slight cleanup might be in order, but not
how you are proposing it. First of all:
- I am against forward struct declarations. I think they decrease code
readability and should be avoided.
- I am against putting comments on #includes. Comments are noise in code
and o
I like this proposal and I support making the language consistent. I wasn't
aware there were so many inconsistencies with increment/decrement
operators.
When I read the RFC I was a little sceptical about the deprecation of
string increment functionality. It's something I used in the past and I see
Have you done any benchmarking in terms of build time? Is there any
tangible difference or is it only theoretical?
Hi,
Did you create an RFC already? Or is this RFC-like discussion?
In either case, if you are asking community to come to a decision, we need
to see some background. Why do you want to change this? What's the benefit?
What's the impact on other maintainers, especially extension maintainers?
Do you
Hi,
I don't think we should be removing such large chunk of functionality in a
minor version. If you want to change the default to throw exceptions,
that's ok. But I wouldn't remove the method in 8.3 or 8.4 and only remove
it in 9.0. What is the advantage to removing the Warning mode?
Regards,
Ka
Hi,
I am not sure if we should still support it. But I don't think it's
unthinkable to expect such feature from PHP. However, personally, I don't
find pass-by-ref that useful in general. The question is whether this
feature is used a lot in the wild.
If we decide to drop support for this, it shou
1 - 100 of 219 matches
Mail list logo
