On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <nikita....@gmail.com> wrote: > https://wiki.php.net/rfc/deprecations_php_7_3 > > Undocumented mbstring function aliases > Yeah, if they're just dumb aliases, then it's a slight gain to narrow the symbol table by removing duplicates. A modest composer package (nay, include file) would be sufficient to provide a bridge for existing projects which use the removed aliases once they're gone. This deprecation isn't *needed*, but it's also fairly low impact. 🤷
> String search functions with integer needle > Agree with stas, the wtf quotient on this one is high. Mitigating this is the availability of strict types, but even still I think deprecating the behavior altogether is a wise move. Callers can easily insert a call to chr() (or IntlChar::chr() ) to maintain the old behavior in a version agnostic way. 😕 > fgetss() function and string.strip_tags filter > "...these functions seem to be of very little utility..." [citation needed] Anecdotally I struggle to imagine the use-case, but my imagination isn't what it once was. There's not a trivial workaround for someone who's dealing with a large/streaming data source from which they want to strip tags. Deprecating this should come at a higher standard of: proving that it is used, providing a userspace replacement, or both. 😤 > Defining a free-standing assert() function > Eww, yeah. I can see that problem. I'm not a huge fan of banning all namespaced assert() function declarations, but it's certainly the most direct "solution" to the problem. A very quick scan of github only shows one effected usage in a repo with no followers/stars apart from the owner. Given the lack of whole-program analysis, it's either ban the declarations, or abandon elision. Frankly, the number of people taking advantage of the free dev-only check is probably way higher than the number trying to define a function called 'assert' so.... 😬 -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
