Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80202
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54AAF3DE.2050508@gmail.com>
References: <003e01d0290b$2387dd30$6a979790$@yahoo.fr>
	<FFF8F5D3-A82A-4A85-8728-79332E274CA1@ajf.me>
	<CAH-PCH5jLdpXpm371SbiiQBE6NP8exGKgDhFyZ8_4X3ZQwv-pQ@mail.gmail.com>
	<54AAF3DE.2050508@gmail.com>
Date: Mon, 5 Jan 2015 23:03:05 +0100
Message-ID: <CAH-PCH60shvNBvePg_OYFkexKXzyYuxx+AprjmTu-24fNCwj_g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, nf.laupretre@yahoo.fr, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d041c408edac3ea050beeda59
Subject: Re: [PHP-DEV] [BugFest] Feature request #38685: str_[i]replace(): Add
 support for (string needle, array replace)
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d041c408edac3ea050beeda59
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 5, 2015 at 9:28 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > usually each BC break would warrant an RFC and a vote, but I'm not sure
> > many people would use str_replace("foo", array("bar"), $subject); and
> > expect the implicit array to string conversion of array("bar") =3D> "Ar=
ray"
> > which also emits a notice.
> > let's see what others think.
>
> I wouldn't consider this a BC break. Anybody who relies on implicit
> array->string conversion has a bug anyway, and we allow that implicit
> conversion to survive only for legacy reasons, but I don't think it
> should drag behind itself the promise we'd never support array parameter
> where there was only string before. In summary, I'd say no BC break here.
> --
> Stas Malyshev
> smalyshev@gmail.com
>

depends on one's definition of bc. mine is that changing anything which
isn't explicitly documented otherwise or as as undefined behavior is a bc
break.
as I mentioned I agree that there should be no otherwise correct code which
depends on this behavior (yet we have seen people complaning about BC break
when we originally introduced the notice on implicit array -> string cast
in php 5.4.0) so I would possibly vote yes on this.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d041c408edac3ea050beeda59--