Re: BC breaking changes in PHP 8.1

On Thu, 23 Sept 2021 at 17:53, Nikita Popov <nikita.ppv@gmail.com> wrote: > I believe the changes in PHP 8.1 with the highest migration burden for > open-source libraries are the additional of tentative return types (aka > "put #[ReturnTypeWillChange] everywhere") and deprecation of null arguments > to internal functions, followed by the float to int precision-loss > deprecation and, depending on project, the Serializable deprecation. > > [...] > > I'm not sure what we can do about that though. Sure, we could stop with the > (runtime) deprecations, only document the change and then directly > implement it at the next major version. That would be much simpler for us > (generating runtime deprecations is actually a major implementation pain, > as well as a big performance concern) and would make minor version upgrades > for libraries much simpler. However, it also removes the ability to address > problems before they turn into fatal errors, e.g. by recording any stray > deprecation warnings in production. > While "put #[ReturnTypeWillChange] everywhere" has been fairly easy... "deprecation of null arguments to internal functions" is a major issue, because they are everywhere, and only really found at run-time... and tbh, I can't explain to anyone why it's so important this will be broken in the future, especially for the majority of projects who are not using strict_types=1. Don't get me wrong, a user/library defined function that says it only wants a string, I get that, but they have full control over it (for their projects) so they can be as strict as they like, or use ?string... but the internals functions have always accepted NULL, and used by everyone. As I noted last week, frameworks use NULL for undefined GET/POST/COOKIE values, so these NULL get everywhere; and it can be useful to distinguish between a value that wasn't set vs an empty string (e.g. when saving to a database, a NULL can be "do not change", which is different to "set this field to an empty string"). One of the projects I work with have gone down the route of "check it, but you should probably stick strval() in every case of strlen(), trim(), strpos(), htmlspecialchars(), strtoupper(), hash(), hash_equals(), simplexml_load_string(), strtotime(), explode(), etc"... which really doesn't seem sensible (one commit was over 200 manually checked/changed lines, and took about 3 days)... the other projects have gone with the "we can stick on 8.0 for a while, hopefully things change". Maybe PHP 8.1 could be updated so these string functions could continue accepting NULL? Craig