Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97095 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84809 invoked from network); 20 Nov 2016 22:42:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Nov 2016 22:42:32 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Received: from [82.113.146.227] ([82.113.146.227:35654] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C2/C2-65233-7D622385 for ; Sun, 20 Nov 2016 17:42:31 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 404C010C011; Sun, 20 Nov 2016 22:42:28 +0000 (GMT) Date: Sun, 20 Nov 2016 22:42:28 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: Nikita Popov cc: PHP internals In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2 From: derick@php.net (Derick Rethans) On Fri, 18 Nov 2016, Nikita Popov wrote: > Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC. I wouldn't deprecate things that 1. have no replacement, 2. are very much in use, or 3. are harmless. __autoload is one of group (2). I think this is used a lot, and would *not* want to deprecate this until PHP 8. I also do not see why (binary) should be removed, as it fits in category 3. In general, I think you should have a good reason *why* to remove them, and just "it's not what we suggest you use" is not good enough. It should be a general *bad* thing, before it should be considered for removal. Right now, the only thing I can think of is removing mbstring.func_overload. For ini settings, you should not throw a deprecation warning if the setting is set to *off*. This covers mbstring.func_overload , but it seems you have changed that since I read this RFC for the first time. cheers, Derick