Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85270
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuRG7RV74uD=pJxB2M3LS9Ty1xB-+TN_ddMpYg4xgtjpwA@mail.gmail.com>
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
	<077401d06268$2b597c30$820c7490$@php.net>
	<CA+kxMuRG7RV74uD=pJxB2M3LS9Ty1xB-+TN_ddMpYg4xgtjpwA@mail.gmail.com>
Date: Fri, 20 Mar 2015 11:31:36 +0100
Message-ID: <CAH-PCH5=QU9mC2+nT1Ax94vSf-5RdRwBYSFvM_=09vN=YqYfpQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: francois@php.net, PHP Internals <internals@lists.php.net>, Zeev Suraski <zeev@zend.com>
Content-Type: multipart/alternative; boundary=047d7b4724ac3b7e790511b5d29f
Subject: Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b4724ac3b7e790511b5d29f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015.03.19. 18:40 ezt =C3=ADrta ("Dan Ackroyd" <danack@basereality.com>):
>
> On 19 March 2015 at 17:14, Fran=C3=A7ois Laupretre <francois@php.net> wro=
te:
>
> > As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion.
> > 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.
>
> What. The. Fuck.
>
> You edited the RFC after the voting had closed? You are not allowed to
> edit an RFC after the voting has occurred.
>
> I don't think we have any rules in place to deal with this; I don't
> think anyone anticipated that anyone would actually try to do this. We
> obviously need an explicit rule for this, but that can wait until 7.0
> is closer to shipping, and we can contemplate RFC rules at leisure.
>
> For now, please revert the changes your made to the RFC after it had
> been closed. And whoever has the power to remove karma, please take
> the power to edit RFCs away from Francois once that has been done.
>
> > Array to string conversion will raise E_DEPRECATED in 7.0, and, then,
fatal error in 7.1 or 7.2.
>
> You are being dumb here as well. We try to avoid breaking code in
> point releases. This BC break can only be done at a major version.
>
> E_DEPRECATED is not a magic bullet - that makes all BC problems go
> away. The reason why we voted on it for 7.0 is that it is a major
> break, but one that is acceptable to be done at a major version. It
> would not be acceptable to change the behaviour in a minor version.
>
> cheers
> Dan
>

We have no reason to think that this wasn't just a honest mistake, so there
is no reason for any sactions.

Personally I agree, we either remove it in 7.0(without prior deprecation as
we voted no for 5.7) or deprecate it in 7.0 and remove in the next major
version.
Everything else is a PITA and against our release process rfc.

--047d7b4724ac3b7e790511b5d29f--