Hi, internals! I want to propose to deprecate one more weird feature of PHP called "comparison of different types" http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.types.
Here you can check one simple example https://3v4l.org/kCOAf to see why it should be deprecated. It would be nice to deprecate all comparison operators between different types and throw an exception later in future version of PHP. Operators that should be allowed for comparison of different types are the following: ==, !=, ===, !==, <>. Operators to deprecate for comparison of different types are the following: >, <, >=, <=, <=> I also think about deprecation of string/object/array comparison with operators like greater/less, because it's hard to understand results for '1000' < '0xabc1' (see https://3v4l.org/o3iLj) or even object comparison https://3v4l.org/5At1l Thanks! 2016-12-27 9:52 GMT+03:00 Stanislav Malyshev <smalys...@gmail.com>: > 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 > >
