# [RFC] Generalize support of negative string offsets

- Thread: https://externals.io/message/90848
- Original archive: https://news-web.php.net/php.internals/90848
- Started by francois@php.net on 2016-01-23T15:45:35+00:00
- Messages: 52
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/90848.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #90848 — francois@php.net — 2016-01-23T15:45:35+00:00

URL: https://externals.io/message/90848#90848

Hi,

Starting discussion about https://wiki.php.net/rfc/negative-string-offsets

Please read and comment.

Regards

François

---

## #90857 — Andrea Faulds — 2016-01-23T21:02:18+00:00

URL: https://externals.io/message/90848#90857 · In reply to: #90848

Hi François,

François Laupretre wrote:

> Starting discussion about https://wiki.php.net/rfc/negative-string-offsets
>
> Please read and comment.

I like this RFC. Being able to use negative offsets helps code 
readability, but it not being universally supported is annoying. I like 
that this brings more consistency.

I particularly like that this is supported for string indexing with the 
[]/{} operator.

At present a negative offset is interpreted as being the maximum string 
length plus that offset, so $str[-1] is equivalent to $str[(2**64 - 1) - 
1]. In practice, this means you will get an empty string and an 
"Uninitialized string offset:" E_NOTICE. It's not useful except for 
extremely large strings and so I suspect that behaviour comes from an 
implementation detail (naïve signed-to-unsigned integer conversion).

What you're proposing is to have the negative offset be interpreted as 
an offset from the end of the string, as the built-in functions do. This 
is more useful, but it's a change of behaviour from the present one, and 
thus a backwards-compatibility break, even if it's unlikely to affect 
real-world code. So, you might wish to mention that.

Also, I think the RFC would be more accessible if you included some 
examples of where to use negative offsets. That would give readers an 
at-a-glance view of what the RFC changes.

Anyway, I like what you're doing here. Thanks for the proposal!

-- 
Andrea Faulds
https://ajf.me/

---

## #90858 — Andrea Faulds — 2016-01-23T21:10:29+00:00

URL: https://externals.io/message/90848#90858 · In reply to: #90857

Hi again,

Andrea Faulds wrote:
> At present a negative offset is interpreted as being the maximum string
> length plus that offset, so $str[-1] is equivalent to $str[(2**64 - 1) -
> 1]. In practice, this means you will get an empty string and an
> "Uninitialized string offset:" E_NOTICE. It's not useful except for
> extremely large strings and so I suspect that behaviour comes from an
> implementation detail (naïve signed-to-unsigned integer conversion).
>
> What you're proposing is to have the negative offset be interpreted as
> an offset from the end of the string, as the built-in functions do. This
> is more useful, but it's a change of behaviour from the present one, and
> thus a backwards-compatibility break, even if it's unlikely to affect
> real-world code. So, you might wish to mention that.

Er, ignore what I just said. Negative string offsets are actually 
special-cased and always produce an "Unitialized string offset" or 
"Invalid string offset" notice. So our current behaviour is in fact 
completely useless, not just mostly. :)

Sorry about that.
-- 
Andrea Faulds
https://ajf.me/

---

## #90920 — francois@php.net — 2016-01-25T14:45:54+00:00

URL: https://externals.io/message/90848#90920 · In reply to: #90858

Hi Andrea,

Le 23/01/2016 22:10, Andrea Faulds a écrit :
>
> Er, ignore what I just said. Negative string offsets are actually
> special-cased and always produce an "Unitialized string offset" or
> "Invalid string offset" notice. So our current behaviour is in fact
> completely useless, not just mostly. :)

Thanks for your comments. Following your suggestion, I just added some 
examples of negative offset usage.

About BC breaks, the RFC just adds support for currently-invalid values. 
In every cases, these values would have generated a notice or a warning, 
and the value would have been considered as zero. So, I consider these 
BC breaks as minor because of error messages. But determining if such BC 
breaks are compatible with a minor release will be the main objective of 
the vote.

Regards

François

---

## #90981 — Julien Pauli — 2016-01-27T14:50:25+00:00

URL: https://externals.io/message/90848#90981 · In reply to: #90920

> Hi Andrea,
>
> Le 23/01/2016 22:10, Andrea Faulds a écrit :
> > […]
>
>
> Thanks for your comments. Following your suggestion, I just added some
> examples of negative offset usage.
>
> About BC breaks, the RFC just adds support for currently-invalid values. In
> every cases, these values would have generated a notice or a warning, and
> the value would have been considered as zero. So, I consider these BC breaks
> as minor because of error messages. But determining if such BC breaks are
> compatible with a minor release will be the main objective of the vote.
>
> Regards
>
> François
>
>
>
> --
> 
> 
>

Hi !

I like it very much.

It is not far from an idea I got in my head since a long time :
allowing string references and C-like character handling in PHP, but
this would require a deep engine patch I've not worked on it yet.

Anyway, happy consistency :-)


Julien.P

---

## #91037 — Nikita Popov — 2016-01-31T22:03:04+00:00

URL: https://externals.io/message/90848#91037 · In reply to: #90848

On Sat, Jan 23, 2016 at 4:45 PM, François Laupretre <francois@php.net>
wrote:

> Hi,
>
> Starting discussion about https://wiki.php.net/rfc/negative-string-offsets
>
> Please read and comment.
>

Just dropping by with a +1 on this proposal. Consistent support is always
good.

The only concern I have is that support of negative indexing will break
symmetry with (proper) arrays, where we cannot support negative indexing.
I.e. this may lead to "Why can I write $str[-1] to get the last character
in a string, but not $array[-1] to get the last element in an array?"
However this is unlikely to be a significant issue. (I do however play with
the thought of reutilizing the obsolete {} indexing syntax to act as offset
indexing instead.)

Nikita

---

## #91038 — Stanislav Malyshev — 2016-01-31T22:14:13+00:00

URL: https://externals.io/message/90848#91038 · In reply to: #91037

Hi!

> The only concern I have is that support of negative indexing will break
> symmetry with (proper) arrays, where we cannot support negative indexing.

I think that was the main source of objections to this proposal in the
past. However, as one might say, string offsets are already not
symmetrical to array offsets - e.g. you can do $array["foo"] but not
$string["foo"].

> However this is unlikely to be a significant issue. (I do however play with
> the thought of reutilizing the obsolete {} indexing syntax to act as offset
> indexing instead.)

I think it may be a good idea to start recommending using {} for string
offsets and [] for arrays. While both syntaxes may work for strings, the
intent (and expected handling of negatives, in this case) is much
clearer when different syntax is used.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #91043 — Julien Pauli — 2016-02-01T09:40:57+00:00

URL: https://externals.io/message/90848#91043 · In reply to: #91038

On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev
<smalyshev@gmail.com> wrote:
> Hi!
>
> > […]
>
> I think that was the main source of objections to this proposal in the
> past. However, as one might say, string offsets are already not
> symmetrical to array offsets - e.g. you can do $array["foo"] but not
> $string["foo"].
>
> > […]
>
> I think it may be a good idea to start recommending using {} for string
> offsets and [] for arrays. While both syntaxes may work for strings, the
> intent (and expected handling of negatives, in this case) is much
> clearer when different syntax is used.

I totally agree here, having 2 different syntaxes for 2 different ways of using
the array for strings is pretty nice.


Julien

---

## #91047 — francois@php.net — 2016-02-01T17:21:42+00:00

URL: https://externals.io/message/90848#91047 · In reply to: #91038

Le 31/01/2016 23:14, Stanislav Malyshev a écrit :
> Hi!
>
> > […]
>
> I think that was the main source of objections to this proposal in the
> past. However, as one might say, string offsets are already not
> symmetrical to array offsets - e.g. you can do $array["foo"] but not
> $string["foo"].
>
> > […]
>
> I think it may be a good idea to start recommending using {} for string
> offsets and [] for arrays. While both syntaxes may work for strings, the
> intent (and expected handling of negatives, in this case) is much
> clearer when different syntax is used.
>

Yes, authorizing array-related '[]' syntax on strings may look fine at 
first sight, but it only brings some unwanted ambiguity for no real 
benefit. And ambiguity increases with the support of negative string 
offsets.

So, I just added a chapter to the RFC, saying that documentation would 
be modified to recommend using the '{}' syntax for string offsets.

Regards

François

---

## #91048 — Nikita Popov — 2016-02-01T17:34:32+00:00

URL: https://externals.io/message/90848#91048 · In reply to: #91038

On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > […]
>
> I think that was the main source of objections to this proposal in the
> past. However, as one might say, string offsets are already not
> symmetrical to array offsets - e.g. you can do $array["foo"] but not
> $string["foo"].
>
> > […]
> with
> > […]
> offset
> > […]
>
> I think it may be a good idea to start recommending using {} for string
> offsets and [] for arrays. While both syntaxes may work for strings, the
> intent (and expected handling of negatives, in this case) is much
> clearer when different syntax is used.


I strongly disagree with this. $str[$offset] is well-recognized, generally
understood syntax that does not require familiarity with language
peculiarities. $str{$offset} might be clear to a Perl programmer, but to
anyone else this is just guesswork, with a typo being a reasonable
assumption.

We should be deprecating this alternative syntax instead of recommending
its use. I was under the impression that we *were* already discouraging its
use and it has already been temporarily deprecated.

Nikita

---

## #91049 — Levi Morrison — 2016-02-01T18:51:38+00:00

URL: https://externals.io/message/90848#91049 · In reply to: #91048

> We should be deprecating this alternative syntax instead of recommending
> its use. I was under the impression that we *were* already discouraging its
> use and it has already been temporarily deprecated.

I agree with Nikita. I think we should be deprecating and removing
`{}` access in favor of `[]`.

---

## #91050 — Stanislav Malyshev — 2016-02-01T21:06:20+00:00

URL: https://externals.io/message/90848#91050 · In reply to: #91048

Hi!

> I strongly disagree with this. $str[$offset] is well-recognized,
> generally understood syntax that does not require familiarity with
> language peculiarities. $str{$offset} might be clear to a Perl
> programmer, but to anyone else this is just guesswork, with a typo being
> a reasonable assumption.

The problem is that while it is generally understood, it's generally
understood wrongly. $str[$offset] is not the same operation as
$array[$offset]. There are many subtle differences. So while at the
first sight it's similar, it leads to "understanding" that is only going
to harm one in the future, when it turns out you really had wrong idea.
I think it's much better to instill the right idea from the start, even
if it means one has to take a brief look in the manual. String offset is
*not* the same as array access.

> We should be deprecating this alternative syntax instead of recommending
> its use. I was under the impression that we *were* already discouraging
> its use and it has already been temporarily deprecated.

I think deprecating it was a mistake and give how much semantic load []
carries - array access, array constructor, now there's proposal to make
it used in deconstructing too - adding string offset to it looks like
bad idea. Different things should use different syntax, as much as possible.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #91052 — bjorn.x.larsson@telia.com — 2016-02-01T22:08:46+00:00

URL: https://externals.io/message/90848#91052 · In reply to: #91050

Den 2016-02-01 kl. 22:06, skrev Stanislav Malyshev:
> Hi!
> 
> > […]
> 
> The problem is that while it is generally understood, it's generally
> understood wrongly. $str[$offset] is not the same operation as
> $array[$offset]. There are many subtle differences. So while at the
> first sight it's similar, it leads to "understanding" that is only going
> to harm one in the future, when it turns out you really had wrong idea.
> I think it's much better to instill the right idea from the start, even
> if it means one has to take a brief look in the manual. String offset is
> *not* the same as array access.
> 
> > […]
> 
> I think deprecating it was a mistake and give how much semantic load []
> carries - array access, array constructor, now there's proposal to make
> it used in deconstructing too - adding string offset to it looks like
> bad idea. Different things should use different syntax, as much as possible.
> 

Yup, you do have a good point here.

Regards //Björn Larsson

---

## #91099 — Nikita Popov — 2016-02-06T15:16:31+00:00

URL: https://externals.io/message/90848#91099 · In reply to: #91050

On Mon, Feb 1, 2016 at 10:06 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > […]
>
> The problem is that while it is generally understood, it's generally
> understood wrongly. $str[$offset] is not the same operation as
> $array[$offset]. There are many subtle differences. So while at the
> first sight it's similar, it leads to "understanding" that is only going
> to harm one in the future, when it turns out you really had wrong idea.
> I think it's much better to instill the right idea from the start, even
> if it means one has to take a brief look in the manual. String offset is
> *not* the same as array access.
>

What are these subtle differences?


> > […]
>
> I think deprecating it was a mistake and give how much semantic load []
> carries - array access, array constructor, now there's proposal to make
> it used in deconstructing too - adding string offset to it looks like
> bad idea. Different things should use different syntax, as much as
> possible.
>

I agree that different things should use different syntax. However, the
point here is that all of array access, ArrayAccess and string offset
access are really the same thing and as such should also use the same
syntax. Array construction and destructuring on the other hand are
different concerns from array access and as such do use a different syntax
(even though it might reuse a token, I do not see a potential for
confusion).

Arguing that string offset access requires a different syntax than array
access to me is the same as arguing that reading an array offset and
reading an offset of an ArrayAccess object also require different syntax.
Sure there are subtle differences between how plain array access works and
how ArrayAccess works (especially once you get around to nested
ArrayAccess), but at its core it's the same operation: Getting an element
from a vector or map like structure using an offset or key. String offset
access falls into the same category.

There is value in emphasizing the difference of two operations by using
different syntax, but there is also much value in using one, and only one,
syntax to cover a set of very tightly related operations, rather than
branching off in a dozen ways in an attempt to accurately capture all
possible idiosyncrasies.

In any case, while this is no doubt an interesting question, and one we
should resolve, it is tangential to this RFC and this RFC should make no
recommendations either way. I would prefer not to be forced to vote against
this RFC due to the inclusion of the unnecessary and unrelated "In the
documentation" section. A different proposal should concern itself with
this matter.

Thanks,
Nikita

---

## #91102 — Stanislav Malyshev — 2016-02-06T21:39:27+00:00

URL: https://externals.io/message/90848#91102 · In reply to: #91099

Hi!

>     if it means one has to take a brief look in the manual. String offset is
>     *not* the same as array access.
> 
> 
> What are these subtle differences?

Negative indexes, string indexes. Array offset is a variable, so it can
be used by-ref, but string offset can not. You can substitute object for
array access, and it would work, but not for string offset. You can do
$foo[1]++ for arrays, but not for string offsets, same with assign-ops.
$foo[1]="bar" works differently - for string offset, it will take only
one letter. $foo[1][1] works for arrays but not string offsets. Same for
[]. $foo[1] = 1 would assign integer for array, but string "1" for strings.

It goes deeper. For arrays, $foo[1] is a regular variable, with pretty
much everything working on it that works on $foo. For strings, $foo[1]
is a very special thing called "string offset", and there are a lot of
things that won't work with it. So if you apply your intuition, it'd
serve you fine with arrays (can I do ++ on $foo[1]? Sure, why not - it's
just a variable). But for string offsets, you have to develop completely
different set of rules, as it is a special entity to which regular
variable rules do not apply.

> I agree that different things should use different syntax. However, the
> point here is that all of array access, ArrayAccess and string offset
> access are really the same thing and as such should also use the same

I think I demonstrated that ArrayAccess and offsets are not the same
thing. At least not currently.
-- 
Stas Malyshev
smalyshev@gmail.com

---

## #91104 — francois@php.net — 2016-02-07T22:19:52+00:00

URL: https://externals.io/message/90848#91104 · In reply to: #91099

Le 06/02/2016 16:16, Nikita Popov a écrit :
>
> In any case, while this is no doubt an interesting question, and one we
> should resolve, it is tangential to this RFC and this RFC should make no
> recommendations either way. I would prefer not to be forced to vote against
> this RFC due to the inclusion of the unnecessary and unrelated "In the
> documentation" section. A different proposal should concern itself with
> this matter.

Right. Just moved the chapter about this syntax recommendation from the 
RFC body to 'Future scope'. So, this is not part of the RFC anymore.

Regards

François

---

## #91110 — Rowan Collins — 2016-02-08T11:10:37+00:00

URL: https://externals.io/message/90848#91110 · In reply to: #91099

Nikita Popov wrote on 06/02/2016 15:16:
> In any case, while this is no doubt an interesting question, and one we
> should resolve, it is tangential to this RFC and this RFC should make no
> recommendations either way. I would prefer not to be forced to vote against
> this RFC due to the inclusion of the unnecessary and unrelated "In the
> documentation" section. A different proposal should concern itself with
> this matter.

There is one case where it is highly relevant - if the aim in the future 
is to make string offsets behave more like array offsets, then this RFC 
should be rejected. My reasoning being that negative offsets are legal 
in array access, with a different meaning, so adding this feature 
increases the difference between string and array indexing.

Many of the other differences are - in theory at least - resolvable. 
e.g. $string[1]++ could be equivalent to $temp = $string[1]; $temp++; 
$string[1] = $temp;

If making string access similar to array access is a lower priority than 
adding features such as the one in this RFC, then the case for switching 
to {} is strengthened, but not conclusive.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #91114 — francois@php.net — 2016-02-08T15:09:53+00:00

URL: https://externals.io/message/90848#91114 · In reply to: #91102

Hi,

Slightly off-topic but, as I was looking for the way to add support for 
'$str[]=' assignments, I found something strange.

Just for curiosity, does someone know a reason for this :

$str = "abc";
$str[1]="z";
var_dump($str); // -> string(3) "zbc" -> Expected

$str = ""; // Empty string
$str[1]="z";
var_dump($str); // -> array(1) { [0]=>string(1) "z" } -> !!!

The input string is converted to an array if it is empty. This becomes 
still funnier with :

$str="a";
$str[] = 'z'; // -> Fatal error : [] operator not supported for strings

$str="";
$str[] = 'z'; // -> OK -> $str gets array(1) { [0]=>string(1) "z" }

Thoughts ?

Regards

François

---

## #91179 — Yasuo Ohgaki — 2016-02-10T06:51:30+00:00

URL: https://externals.io/message/90848#91179 · In reply to: #91114

Hi Francois,


> Slightly off-topic but, as I was looking for the way to add support for
> '$str[]=' assignments, I found something strange.
>
> Just for curiosity, does someone know a reason for this :
>
> $str = "abc";
> $str[1]="z";
> var_dump($str); // -> string(3) "zbc" -> Expected
>
> $str = ""; // Empty string
> $str[1]="z";
> var_dump($str); // -> array(1) { [0]=>string(1) "z" } -> !!!
>
> The input string is converted to an array if it is empty. This becomes still
> funnier with :
>
> $str="a";
> $str[] = 'z'; // -> Fatal error : [] operator not supported for strings
>
> $str="";
> $str[] = 'z'; // -> OK -> $str gets array(1) { [0]=>string(1) "z" }
>
> Thoughts ?

PHP should raise `E_WARNING` errors for them as other scalar, IMO.

php > $v=1;
php > $v[] = 'z';
PHP Warning:  Cannot use a scalar value as an array in php shell code on line 1

php > $v=TRUE;
php > $v[] = 'z';
PHP Warning:  Cannot use a scalar value as an array in php shell code on line 1

It seems "" is treated just like NULL/FALSE

php > $v=null;
php > $v[] = 'z';
php > var_dump($v);
array(1) {
  [0]=>
  string(1) "z"
}
php > $v=false;
php > $v[] = 'z';
php > var_dump($v);
array(1) {
  [0]=>
  string(1) "z"
}

 `NULL` may become any type of variables, but empty string and `FALSE` should
behave like 'scalar' variable. This could be largest BC of this RFC,
but it's consistent with int variable.

php > $v=0;
php > $v[] = 'z';

Warning: Cannot use a scalar value as an array in php shell code on line 1


BTW, what would happen with $var{} = 'str'?

php > $v='abc';
php > $v{} = 'str';
PHP Parse error:  syntax error, unexpected '}' in php shell code on line 1

Currently, it's not allowed. It may behave like $v .= 'str'. I'm not
sure if PHP should. It looks consistent syntax with array.
i.e. "$v[] = $val" adds $val as last element.

Behavior regarding array. (a bit off topic, but error level should
match with new string '{}' errors.)

php > error_reporting(-1);
php > $v=array();
php > $v .= 'abc';

Notice: Array to string conversion in php shell code on line 1
php > var_dump($v);
string(8) "Arrayabc"

This insane string assignment raises E_NOTICE. PHP may be better to
raise `E_WARNING` for this kind of invalid assignments just like

php > $v=1;
php > $v[] = 'z';
PHP Warning:  Cannot use a scalar value as an array in php shell code on line

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #91180 — Yasuo Ohgaki — 2016-02-10T07:00:06+00:00

URL: https://externals.io/message/90848#91180 · In reply to: #91179

> Behavior regarding array. (a bit off topic, but error level should
> match with new string '{}' errors.)
>
> php > error_reporting(-1);
> php > $v=array();
> php > $v .= 'abc';
>
> Notice: Array to string conversion in php shell code on line 1
> php > var_dump($v);
> string(8) "Arrayabc"
>
> This insane string assignment raises E_NOTICE. PHP may be better to
> raise `E_WARNING` for this kind of invalid assignments just like

Additional comment on this

php > $v=array(1,2,3);
php > $v .= 'abc';

Notice: Array to string conversion in php shell code on line 1
php > var_dump($v);
string(8) "Arrayabc"

I think $v .= 'abc' should not destroy array variable. It's minor issue, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #91182 — francois@php.net — 2016-02-10T14:34:07+00:00

URL: https://externals.io/message/90848#91182 · In reply to: #90848

Hi,

I just added support for '[]' on strings and '{}' to the PR.

Examples :

$string[] = 'a'; // equivalent to : $string[strlen($string)]

$string{} = 'a'; // For consistency

With this change, AFAIK, '{}' and '[]' notations are handled exactly the 
same way (the only difference was that the content inside curly braces 
was not optional).

This is not strictly in the scope of negative offsets. So, if you think 
it must be part of a separate RFC, I will remove it.

Thoughts ?

Regards

François

---

## #91183 — Dan Ackroyd — 2016-02-10T14:34:54+00:00

URL: https://externals.io/message/90848#91183 · In reply to: #91180

> Additional comment on this
>
> php > $v=array(1,2,3);
> php > $v .= 'abc';
>
> I think $v .= 'abc' should not destroy array variable. It's minor issue, though.

That is the current behaviour. Trying to slip "bug fixes" into RFCs is
a very bad pattern to follow.

If this should be fixed, it should be done as part of a separate RFC.

> This insane string assignment raises E_NOTICE. PHP may be better to
> raise `E_WARNING` for this kind of invalid assignments just like

François already wrote an RFC for this
https://wiki.php.net/rfc/array-to-string that passed, but apparently
could not be implemented safely, which is a shame. That RFC needs to
be resurrected imo. But again, changing that behaviour needs to be
separate, and not part of this RFC.

cheers
Dan

---

## #91184 — francois@php.net — 2016-02-10T14:42:19+00:00

URL: https://externals.io/message/90848#91184 · In reply to: #91183

Le 10/02/2016 15:34, Dan Ackroyd a écrit :
> 
> > […]
>
> That is the current behaviour. Trying to slip "bug fixes" into RFCs is
> a very bad pattern to follow.
>
> If this should be fixed, it should be done as part of a separate RFC.
>
> > […]
>
> François already wrote an RFC for this
> https://wiki.php.net/rfc/array-to-string that passed, but apparently
> could not be implemented safely, which is a shame. That RFC needs to
> be resurrected imo. But again, changing that behaviour needs to be
> separate, and not part of this RFC.

Sure. All of this is interesting, but out of scope for this RFC.

My initial question was just about the fact that empty strings are not 
handled like other strings, regarding offset assignments (empty strings 
are silently converted to arrays).

Regards

François

---

## #91185 — Dan Ackroyd — 2016-02-10T14:49:51+00:00

URL: https://externals.io/message/90848#91185 · In reply to: #91182

> Hi,
>
> I just added support for '[]' on strings and '{}' to the PR.
>
> Examples :
>
> $string[] = 'a'; // equivalent to : $string[strlen($string)]
>
> $string{} = 'a'; // For consistency

Unless I'm missing some subtleties, that appears to just be a more
confusing version of string concatenation.

$string[] = 'a';

is equivalent to :

$string .= 'a';

Is that correct?

> This is not strictly in the scope of negative offsets. So, if you think it
> must be part of a separate RFC, I will remove it.

It seems unnecessary. Unless I've misunderstood what it does, it's
just a complete duplication of functionality we already have (, in a
way that is likely to confuse people, imo) and having duplicate
functionality is not so good.

At the very least it needs to be part of a separate vote option - but
my opinion is that it's not needed at all, and should be left out
entirely.

cheers
Dan

---

## #91191 — Stanislav Malyshev — 2016-02-11T06:27:20+00:00

URL: https://externals.io/message/90848#91191 · In reply to: #91182

Hi!

> I just added support for '[]' on strings and '{}' to the PR.
> 
> Examples :
> 
> $string[] = 'a'; // equivalent to : $string[strlen($string)]
> 
> $string{} = 'a'; // For consistency

That's probably not a good idea, and certainly is not good for the RFC -
the patch now does two unrelated things.

> This is not strictly in the scope of negative offsets. So, if you think
> it must be part of a separate RFC, I will remove it.

Yes, I think so. And I also thing it is a bad idea. We already have a
way to add stuff to the string - it's .= operator. Adding another weird
way to do it IMO is not good.

-- 
Stas Malyshev
smalyshev@gmail.com

---

Next page: https://externals.io/message/90848.md?page=2