Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91206
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 76360 invoked from network); 11 Feb 2016 13:30:41 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 11 Feb 2016 13:30:41 -0000
Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; 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:23481] helo=smtp2-g21.free.fr)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 32/DA-25203-00D8CB65 for <internals@lists.php.net>; Thu, 11 Feb 2016 08:30:41 -0500
Received: from [127.0.0.1] (unknown [82.240.16.115])
	(Authenticated sender: flaupretre@free.fr)
	by smtp2-g21.free.fr (Postfix) with ESMTPSA id F31DC4B016F;
	Thu, 11 Feb 2016 14:27:58 +0100 (CET)
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
References: <56A3A01F.1020500@php.net> <56BB4A5F.3060906@php.net>
 <56BC29C8.9070308@gmail.com>
 <CAGa2bXaJ1dphqr8MXWXtUkicx1eP-o21SLQtf_MxoVb2o823wg@mail.gmail.com>
 <56BC3372.1010308@gmail.com>
 <CAGa2bXbWnLkp3mfQBNbOxJxy8U0hNBA7e_RbiekJrfC4YFEgbg@mail.gmail.com>
 <56BC7BB6.6070705@gmx.de> <56BC829C.1040608@gmail.com>
Message-ID: <56BC8CF8.4050105@php.net>
Date: Thu, 11 Feb 2016 14:30:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BC829C.1040608@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 160211-0, 11/02/2016), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Le 11/02/2016 13:46, Rowan Collins a écrit :
> Christoph Becker wrote on 11/02/2016 12:16:
>> Appending to an array always adds a single element only, consider
>>
>>    $a = [1,2,3];
>>    $a[] = [4,5];
>>
>> The suggested syntax for strings would concatenate an arbitrary amount
>> of elements (characters) to a string.  IMHO, this would not be
>> consistent, but rather confusing.  The alternative interpretation to
>> append the first character only, would be confusing as well (besides
>> there would be issues with regard to multibyte character encodings).
>
> Indeed, this is a big problem with making the string offset
> functionality richer in general, because PHP has no "char" type, only a
> single-character string. This leads to some odd things:
>
> // string[0] returns a one-char string, which has an element [0], so you
> can keep adding [0] for as long as you like:
> $foo = 'abc';
> echo $foo[0][0][0][0][0]; // a
>
> // assignment to an offset only overwrites one character, but the source
> can be a string of any length:
> $foo = 'abc';
> $foo[0] = 'zzz';
> echo $foo; // zbc
>
> String offsets simply can't behave like array offsets within PHP's
> current type system, which is why I favour dedicating {} syntax to them,
> and making it work *usefully*, rather than trying to make it look like
> arrays. Then, it would be less surprising for $string{-1} to behave
> differently from $array[-1], and that $string{} is a syntax error.

In addition to string offsets, which will need to keep the same behavior 
for BC reasons, I had the idea of string 'ranges'. These could be 
expressed as 'str{<offset>:<length>}'. These 'ranges' would provide an 
alternate and more readable syntax for eveything you can do with 
substr() and substr_replace() :

$str = "abc";
echo $str{0:2}; // -> "ab"

$str{0:1} = 'xyz'; // -> "xyzbc"

$str{-2:} = 'foo'; // -> "xyzfoo"

$str{1:0} = 'bar'; // -> "xbaryzfoo"

With such syntax, '$str{<offset>)' assignments would still take the 
first character only, and 'str{<offset>:1}' would replace the character 
with the whole string.

Anyway, this is for another RFC. Thoughts ?

Regards

François