On Thu, 23 Sept 2021 at 17:53, Nikita Popov <nikita....@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
