Hi! >> https://wiki.php.net/rfc/deprecations_php_7_2
Reading through the list, I find several categories: Completely ok: (unset) - don't see any sane use case anyway gmp_random Can cause breakage but it's ok: $php_errormsg __autoload mbstring.func_overload parse_str() - people can use it in functions, it doesn't have to be globals. But it's cleaner with second arg. $errcontext Don't see a reason to remove: (binary) cast and b"" - yes, they are not currently doing anything. But they don't also hurt anything. High breakage potential: each() - I've seen a lot of code using each. Yes, it's not the best way. A lot of people write code not in absolutely best way but in a way they like to. Argument about list() proposed in RFC makes little sense to me - since problem is with list() and not each() why each() should be deprecated because of it? And I certainly object its removal. create_function() - yes, there are closures now. But there's a lot of code created when there were none, and that code works, and there's no reason to break it. I'd probably be OK with deprecation warning but not with removal. Special case: assert() - if the string arg is a security issue, deprecating it achieves nothing. So I'm not sure I understand the argument for deprecation - if string assert is a problem we probably should make assert() construct instead check if assert is used in eval form, not by argument count? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
