Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91231
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.54 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>, =?UTF-8?Q?Fran=c3=a7ois_Laupretre?=
 <francois@php.net>
References: <56A3A01F.1020500@php.net> <56BC988F.7080101@php.net>
 <D9.BC.25203.806BCB65@pb1.pair.com> <56BD1CD4.8070206@php.net>
 <CAF+90c89n8pDCh4O3J5DBTao_8+1ON0TnJTxg-GbbROPorFyGg@mail.gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
Message-ID: <56C14AC6.7060307@gmail.com>
Date: Sun, 14 Feb 2016 19:49:26 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c89n8pDCh4O3J5DBTao_8+1ON0TnJTxg-GbbROPorFyGg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> This fix has been merged into master (targeting 7.1), thanks!

I'm not sure that was such a good idea (sorry, didn't have time to write
about it before the weekend). Introducing a new warning into previously
working code is a BC break, and one that wasn't even discussed in its
own thread. Moreover, there's one more BC break in this patch - before
it, for this code:

$str = "abc";
$str{4} = '';
var_dump($str);

the $str was string of length 5, with this fix it would be string of
length 3, unchanged. Which may break other code (e.g. one composing
complex formats) in very subtle ways. And I'm not sure that current
behavior is an improvement.

> Another issue mentioned in this thread is the spurious array conversion
> that happens for empty strings. We have an existing bug report for this:
> https://bugs.php.net/bug.php?id=53432 I've created a PR to fix this
> issue: https://github.com/php/php-src/pull/1764 If there are no
> objections, I'll merge this for 7.1 as well.

This one looks like a bug, converting string to array is really weird.
And one more reason to never use [] for string offsets - clearly, the
bug stems out of confusion between arrays operation (which expects
conversion to array) and string operation (which expects string).
In any case, this needs a note in UPGRADING as behavior change.
-- 
Stas Malyshev
smalyshev@gmail.com