Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85221
Return-Path: <francois@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 299 invoked from network); 19 Mar 2015 17:14:44 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 19 Mar 2015 17:14:44 -0000
Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
X-PHP-List-Original-Sender: francois@php.net
X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr  
Received: from [212.27.42.2] ([212.27.42.2:48636] helo=smtp2-g21.free.fr)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 23/B1-25408-2040B055 for <internals@lists.php.net>; Thu, 19 Mar 2015 12:14:43 -0500
Received: from moorea (unknown [82.240.16.115])
	by smtp2-g21.free.fr (Postfix) with ESMTP id E8D254B0194;
	Thu, 19 Mar 2015 18:13:19 +0100 (CET)
Reply-To: <francois@php.net>
To: "'Zeev Suraski'" <zeev@zend.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
In-Reply-To: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
Date: Thu, 19 Mar 2015 18:14:33 +0100
Message-ID: <077401d06268$2b597c30$820c7490$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIqkhECzNWHmquFHEtotR9EeyhR/ZxvqMLA
Content-Language: fr
X-Antivirus: avast! (VPS 150319-0, 19/03/2015), Outbound message
X-Antivirus-Status: Clean
Subject: RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
From: francois@php.net (=?UTF-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Zeev Suraski [mailto:zeev@zend.com]
>
> https://wiki.php.net/rfc/array-to-string (which I voted yes to) =
deviates
> from our guidelines of deprecating features first, and removing them
> later;  It=E2=80=99s addressed in the RFC =E2=80=93 but I=E2=80=99m a =
bit worried that this opens
> the door to jumping from any sort of notice/warning into errors or =
removed
> features without any deprecation phase.
>=20
> In comparison, in Nikita=E2=80=99s RFC for removing E_STRICT =E2=80=93 =
there aren=E2=80=99t any
> proposed =E2=80=98jumps=E2=80=99 to E_RECOVERABLE_ERROR that =
don=E2=80=99t first go through
> E_DEPRECATED.
>=20
> Should we not go through this deprecation cycle, even if may feel =
anxious
> to get rid of this behavior?

Sorry for the delay but I could not send emails during the last 3 weeks.

As you may have noticed if you had a look at the RFC or twitter, I have =
decided to follow people's suggestion. Array to string conversion will =
raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2.

Please note that the switch from E_DEPRECATED to fatal error won't =
require any new RFC/discussion/vote as the fatal error is considered as =
approved. I just introduce an E_DEPRECATED phase for 7.0.

Regards

Fran=C3=A7ois