Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <753c3900-0d59-8d0d-3a53-863f42465b49@gmail.com>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <CAF+90c8+PKJMzD3GM=VJDi5wCWArZhY0r7=sHv4U-wNXTpn7aA@mail.gmail.com> <753c3900-0d59-8d0d-3a53-863f42465b49@gmail.com>
Date: Tue, 27 Dec 2016 14:33:29 +0300
Message-ID: <CAEbg-4aiz4u5kimrDeXgKT1dd+vtuZOEAUjvkwqkEv44z4cJ4A@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11427400af1d160544a238e8
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--001a11427400af1d160544a238e8
Content-Type: text/plain; charset=UTF-8

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 <smalyshev@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
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11427400af1d160544a238e8--