Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Generalize support of negative string offsets »

[RFC] Generalize support of negative string offsets

php.internals

François Laupretre

10 years ago
Hi, Starting discussion about https://wiki.php.net/rfc/negative-string-offsets Please read and comment. Regards François

Andrew Faulds

10 years ago
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/

Andrew Faulds

10 years ago
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/

François Laupretre

10 years ago
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

Julien Pauli

10 years ago
On Mon, Jan 25, 2016 at 3:45 PM, François Laupretre <francois@php.net> wrote:
> 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 > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
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

Nikita Popov

10 years ago
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

Stas Malyshev

10 years ago
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

Julien Pauli

10 years ago
On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> 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.
I totally agree here, having 2 different syntaxes for 2 different ways of using the array for strings is pretty nice. Julien

François Laupretre

10 years ago
Le 31/01/2016 23:14, Stanislav Malyshev a écrit :
> 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. >
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

Nikita Popov

10 years ago
On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> 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.
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

Levi Morrison

10 years ago
> 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 `[]`.

Stas Malyshev

10 years ago
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

Björn Larsson

10 years ago
Den 2016-02-01 kl. 22:06, skrev Stanislav Malyshev:
> 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. >
Yup, you do have a good point here. Regards //Björn Larsson

Nikita Popov

10 years ago
On Mon, Feb 1, 2016 at 10:06 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> 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. >
What are these subtle differences?
> > 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. >
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

Stas Malyshev

10 years ago
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

François Laupretre

10 years ago
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

Yasuo Ohgaki

10 years ago
Hi Francois, On Tue, Feb 9, 2016 at 12:09 AM, François Laupretre <francois@php.net> wrote:
> 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

Yasuo Ohgaki

10 years ago
On Wed, Feb 10, 2016 at 3:51 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> 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

François Laupretre

10 years ago
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

Rowan Collins

10 years ago
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]

François Laupretre

10 years ago
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

Dan Ackroyd

10 years ago
On 10 February 2016 at 14:34, François Laupretre <francois@php.net> wrote:
> 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

Stas Malyshev

10 years ago
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

Yasuo Ohgaki

10 years ago
Hi Stas, On Thu, Feb 11, 2016 at 3:27 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> >> 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.
RFC must maintain consistency across existing features/specifications, IMHO. We already have too many inconsistencies and scattered RFCs will make things worse certainly. Making patch and/or RFC simple is not the reason why we have RFC, but to have full featured/discussed/consistent changes to PHP. Aren't we better to have consistent/complete RFCs almost always? Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Stas Malyshev

10 years ago
Hi!
> RFC must maintain consistency across existing features/specifications,
There's a lot of things people call "consistency", apparently. I don't see inventing new syntax for doing concatenation to have anything to do with consistency.
> make things worse certainly. Making patch and/or RFC simple is not the > reason why we have RFC, but to have full featured/discussed/consistent
To have simple patch is not really why we have RFCs, of course. But having simple (or not overly complex) RFC is a sign of a good RFC. On the contrary, overly complex and convoluted ones make it hard to review them and usually lead to unintended consequences and mistakes since it is hard to predict the outcomes in such complexity.
> Aren't we better to have consistent/complete RFCs almost always?
Since everybody defines "consistent" to mean pretty much anything they want, there's no answer to this question.
-- Stas Malyshev smalyshev@gmail.com

Yasuo Ohgaki

10 years ago
Hi Stas, On Thu, Feb 11, 2016 at 4:08 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> RFC must maintain consistency across existing features/specifications, > > There's a lot of things people call "consistency", apparently. I don't > see inventing new syntax for doing concatenation to have anything to do > with consistency. > >> make things worse certainly. Making patch and/or RFC simple is not the >> reason why we have RFC, but to have full featured/discussed/consistent > > To have simple patch is not really why we have RFCs, of course. But > having simple (or not overly complex) RFC is a sign of a good RFC. On > the contrary, overly complex and convoluted ones make it hard to review > them and usually lead to unintended consequences and mistakes since it > is hard to predict the outcomes in such complexity. > >> Aren't we better to have consistent/complete RFCs almost always? > > Since everybody defines "consistent" to mean pretty much anything they > want, there's no answer to this question.
Since Francois removed the section, it's not important for this discussion anymore. Anyway, all of us know that main source of complaints about PHP is lack of consistency. Inconsistent APIs across modules are acceptable. It's modules after all. However, basic language constructs like [] and {} are better to have predictable/consistent behaviors. i.e. how it works, raised errors. This RFC improves inconsistent behaviors a lot. Why not to add $str{} = 'string'? It's not complex nor BC as it raises syntax error currently. It does not worth the effort having other RFCs for - $str{} = 'string' - error level/message tweaks. i.e. Raise the same error for similar situations. - and so on. I agree small changes are easier to review, but it may leave lots of obvious inconsistency in PHP. We have too many of them already. Making RFC and pass the vote is not easy task. Authors may not have time for RFCs for clean ups. Every each one of RFC should try to reduce number of obvious inconsistency as much as possible, IMHO. Otherwise, we end up with increasing them. Code review being a little more difficult is not too important issue, but leaving behind obvious inconsistency is. Let's concentrate improvements to be complete. We have plenty of time before 7.1 release. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Christoph Becker

10 years ago
On 11.02.2016 at 12:12, Yasuo Ohgaki wrote:
> Anyway, all of us know that main source of complaints about PHP is lack > of consistency. Inconsistent APIs across modules are acceptable. It's > modules after all. However, basic language constructs like [] and {} are > better to have predictable/consistent behaviors. i.e. how it works, raised > errors.
ACK.
> This RFC improves inconsistent behaviors a lot. Why not to add > $str{} = 'string'? It's not complex nor BC as it raises syntax error currently.
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).
-- Christoph M. Becker

Rowan Collins

10 years ago
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. Regards,
-- Rowan Collins [IMSoP]

Nikita Popov

10 years ago
On Thu, Feb 11, 2016 at 1:46 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> 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
The issue here is not an inherent problem with string offsets, it's simply yet another artifact of PHP's overly lenient nature. If I create an IntArray class that implements ArrayAccess, I don't think you would be much surprised if doing $intArray[$i] = "123abc" would end up storing the value int(123), as this just conforms to PHP's usual silent, lossy type conversion semantics. It's the same with string offsets, just with the conversion happening from string to single-character-string. Just having a different syntax, writing $foo{0} = 'zzz' instead of $foo[0] = 'zzz' does not make the implicit truncation behavior any more obvious or reasonable. If we want to actually make it less confusing, what we should do is throw a warning if such a truncation occurs. And that's something that can be done independently of syntax. Similarly, Stas' comments on how things like $string[0] ^= "\xf0" do no work, are not a reason to promote a different string offset syntax -- that wouldn't actually *solve* anything. Instead we should strive to make these things work as expected. If I can write $string[0] = $string[0] ^ "\xf0" it stands to reason that $string[0] ^= "\xf0" should work as well. Nikita

Rowan Collins

10 years ago
Nikita Popov wrote on 11/02/2016 13:14:
> The issue here is not an inherent problem with string offsets, it's > simply yet another artifact of PHP's overly lenient nature. If I > create an IntArray class that implements ArrayAccess, I don't think > you would be much surprised if doing $intArray[$i] = "123abc" would > end up storing the value int(123), as this just conforms to PHP's > usual silent, lossy type conversion semantics. It's the same with > string offsets, just with the conversion happening from string to > single-character-string.
Eh, I can see the logic, but there is no such type as "single-character string"; that's why I said PHP's type system was to blame - if there was a "char" type, things become simpler to explain: - the assignment case would be a case of implicit conversion from string to char - the $foo[0][0] case could give an error that you can't offset a char, and "$bar = $foo[0]; echo $bar[0];" would be able to give the same error I'd like to stress that these are just a couple of examples; I'm sure there are other "anomalies".
> Just having a different syntax, writing $foo{0} = 'zzz' instead of > $foo[0] = 'zzz' does not make the implicit truncation behavior any > more obvious or reasonable.
No, but it gives a general warning to the reader that this is a bit like array access, but not quite.
> If we want to actually make it less confusing, what we should do is > throw a warning if such a truncation occurs. And that's something that > can be done independently of syntax.
Agreed.
> Instead we should strive to make these things work as expected.
Agreed for the cases where it is obvious what is expected. Sometimes, though, I think it is not reasonable to expect the same behaviour as for an array, and so "striving to make string offsets work well" and "striving to make string offsets work the same as array offsets" are different, and possibly conflicting, goals. Regards,
-- Rowan Collins [IMSoP]

Stas Malyshev

10 years ago
Hi!
> Just having a different syntax, writing $foo{0} = 'zzz' instead of $foo[0] > = 'zzz' does not make the implicit truncation behavior any more obvious or > reasonable. If we want to actually make it less confusing, what we should
It makes it clear the operation you are dealing with is not array access and is not bound by its rules, but another operation with (possibly) different rules which you need to learn.
> Similarly, Stas' comments on how things like $string[0] ^= "\xf0" do no > work, are not a reason to promote a different string offset syntax -- that > wouldn't actually *solve* anything. Instead we should strive to make these
That would solve the situation where we imply that strings are like arrays by using same syntax only to break that promise with many operations.
> things work as expected. If I can write $string[0] = $string[0] ^ "\xf0" it > stands to reason that $string[0] ^= "\xf0" should work as well.
That would be much harder to do and largely pointless unless we make string offsets be real zvals. Which I strongly recommend against - we have enough trouble with pointer-like nature of references, one more pointer-like time would produce huge amount of trouble.
-- Stas Malyshev smalyshev@gmail.com

François Laupretre

10 years ago
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

François Laupretre

10 years ago
Le 11/02/2016 13:16, Christoph Becker a écrit :
> > 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). >
Not exactly, the '$str[]' syntax I suggested would have worked the same as '$str[strlen($str)]': it would have appended the first character only. Concerns about multi-bytes characters are clearly out of scope, as all string offset operations handle bytes only. Regarding consistency, I understand the arguments about the fact that string concatenation should be done using the '.' operator, but do you know that this is already supported : $str="abc"; $str[3]='def'; // $str="abcd" $str[10]='xyz'; // $str = "abc x"; So, my feeling was that, since '$str[strlen($str)]' is supported, we *already* support concatenation using string offset syntax. So, supporting '[]' and '{}' as a shortcut for '[strlen($str)]' was just a small addition for a better consistency and a more intuitive behavior. Stas and Yasuo are both right. It is not exactly related to negative string offsets but, on the other side, I probably won't bother opening an RFC for such a small change. That's why, if there had been a consensus, I would have added it to the current RFC. Regards François

Stas Malyshev

10 years ago
Hi!
> Anyway, all of us know that main source of complaints about PHP is lack > of consistency. Inconsistent APIs across modules are acceptable. It's > modules after all. However, basic language constructs like [] and {} are > better to have predictable/consistent behaviors. i.e. how it works, raised > errors.
They do have predictable behavior. Again, "consistent" here does not have any defined meaning as far as I can see, given how many people use it to mean so many different things. It became sort of a shortcut - instead of explaining why the change is good, you just say "for consistency" and expect everybody to nod and agree. I don't think it works.
> This RFC improves inconsistent behaviors a lot. Why not to add > $str{} = 'string'? It's not complex nor BC as it raises syntax error currently.
Because it is not needed and it is an unnecessary weird syntax for the operation we already have a syntax for - string concatenation. Moreover, it borrows syntax from another operation - string offset - while doing totally different thing ($a{1} = 'foo' would only use one character - 'f', but $a{} = 'foo' would use the whole string, right?). Moreover, while there is a practical need in string offsets (though I would say making them writable is a bit questionable) there is no need to invent syntax for concatenation, we already have it.
> It does not worth the effort having other RFCs for > - $str{} = 'string'
Correct, because nobody needs it and it is a bad idea.
> I agree small changes are easier to review, but it may leave lots of > obvious inconsistency in PHP. We have too many of them already.
If you have examples of "obvious inconsistency", name them and we will discuss it. {} is not such example.
> Making RFC and pass the vote is not easy task. Authors may not have > time for RFCs for clean ups.
Understandable, not everyone has time to contribute to PHP. Those who have the time, do, and we are grateful to them. However, if somebody doesn't have the time, that is not the reason to lower our standards.
-- Stas Malyshev smalyshev@gmail.com

Lester Caine

10 years ago
On 11/02/16 18:07, Stanislav Malyshev wrote:
>> It does not worth the effort having other RFCs for >> > - $str{} = 'string' > Correct, because nobody needs it and it is a bad idea. > >> > I agree small changes are easier to review, but it may leave lots of >> > obvious inconsistency in PHP. We have too many of them already. > If you have examples of "obvious inconsistency", name them and we will > discuss it. {} is not such example.
One thing that everybody agrees on is that the procedural API for arrays is 'somewhat clunky'? But fixing it by renaming, changing parts to better match other parts and so on has hit brick walls because of BC. That an OO array API that is consistent and expandable has also been agreed in the past, but no one has the time or 'urge' or pursue that path? Along with the Unicode string OO extension? So do we not need perhaps a clean road map on the procedural API to establish just where things like 'negative string offsets' fit into the whole picture? That array and string API's are now inextricably linked had been pointed out in the past and we now have to live with the results, but a PHP8 change may be to split the two syntaxes so one can look at code and not have to work out if some variable buried in a cleaver piece of software is in indexed string or simply an array element?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

François Laupretre

10 years ago
Le 11/02/2016 07:27, Stanislav Malyshev a écrit :
> 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. >
OK. Removed. François

François Laupretre

10 years ago
String offsets are full of oddities : $str = "abc"; $str{0} = ''; var_dump($str); // -> string(3) "bc" (read as "\0bc") Assigning an empty string to a string offset inserts a null byte because the string length is not checked in zend_assign_to_string_offset(). I see this as a bug. IMO, this case should raise a warning and the string should remain unchanged. Thoughts before I register a bug and a PR ? Regards François

Andrew Faulds

10 years ago
Hi François, François Laupretre wrote:
> String offsets are full of oddities : > > $str = "abc"; > $str{0} = ''; > var_dump($str); // -> string(3) "bc" (read as "\0bc") > > Assigning an empty string to a string offset inserts a null byte because > the string length is not checked in zend_assign_to_string_offset(). > > I see this as a bug. IMO, this case should raise a warning and the > string should remain unchanged. > > Thoughts before I register a bug and a PR ?
Wow, that's quite egregious. I think this should be considered a bug and fixed as soon as possible. Whether it should go into 7.0.x or 7.1 is possibly a matter for debate, though. Thanks
-- Andrea Faulds https://ajf.me/

François Laupretre

10 years ago
Le 11/02/2016 17:25, Andrea Faulds a écrit :
> Hi François, > > François Laupretre wrote: >> String offsets are full of oddities : >> >> $str = "abc"; >> $str{0} = ''; >> var_dump($str); // -> string(3) "bc" (read as "\0bc") >> >> Assigning an empty string to a string offset inserts a null byte because >> the string length is not checked in zend_assign_to_string_offset(). >> >> I see this as a bug. IMO, this case should raise a warning and the >> string should remain unchanged. >> >> Thoughts before I register a bug and a PR ? > > Wow, that's quite egregious. I think this should be considered a bug and > fixed as soon as possible. Whether it should go into 7.0.x or 7.1 is > possibly a matter for debate, though. > > Thanks >
OK. Bug registered (https://bugs.php.net/bug.php?id=71572) along with PR (https://github.com/php/php-src/pull/1761). Can someone please review/merge the PR and close the bug ? Thanks François

Nikita Popov

10 years ago
On Fri, Feb 12, 2016 at 12:44 AM, François Laupretre <francois@php.net> wrote:
> Le 11/02/2016 17:25, Andrea Faulds a écrit : > >> Hi François, >> >> François Laupretre wrote: >> >>> String offsets are full of oddities : >>> >>> $str = "abc"; >>> $str{0} = ''; >>> var_dump($str); // -> string(3) "bc" (read as "\0bc") >>> >>> Assigning an empty string to a string offset inserts a null byte because >>> the string length is not checked in zend_assign_to_string_offset(). >>> >>> I see this as a bug. IMO, this case should raise a warning and the >>> string should remain unchanged. >>> >>> Thoughts before I register a bug and a PR ? >>> >> >> Wow, that's quite egregious. I think this should be considered a bug and >> fixed as soon as possible. Whether it should go into 7.0.x or 7.1 is >> possibly a matter for debate, though. >> >> Thanks >> >> > OK. Bug registered (https://bugs.php.net/bug.php?id=71572) along with PR ( > https://github.com/php/php-src/pull/1761). > > Can someone please review/merge the PR and close the bug ? >
This fix has been merged into master (targeting 7.1), thanks! 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. Nikita

Stas Malyshev

10 years ago
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

Yasuo Ohgaki

10 years ago
Hi all, On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> 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.
I fully agree {} and [] usage. - {} only for string - [] only for array Simple is better if it satisfies all of our needs. Since PHP allowed [] for strings, how about allow it, but deprecate it by doc in 7.1, deprecate(Raise error) it in 7.2, then remove it by 7.3? Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Pierre Joye

10 years ago
On Feb 15, 2016 1:15 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
> > Hi all, > > On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev > <smalyshev@gmail.com> wrote: > >> 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. > > I fully agree {} and [] usage. > - {} only for string > - [] only for array > Simple is better if it satisfies all of our needs. > > Since PHP allowed [] for strings, how about allow it, but deprecate it > by doc in 7.1, deprecate(Raise error) it in 7.2, then remove it by > 7.3?
If anything then it can be removed by 8.

Yasuo Ohgaki

10 years ago
Hi Pierre, On Mon, Feb 15, 2016 at 4:01 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Feb 15, 2016 1:15 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote: >> >> Hi all, >> >> On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev >> <smalyshev@gmail.com> wrote: >> >> 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. >> >> I fully agree {} and [] usage. >> - {} only for string >> - [] only for array >> Simple is better if it satisfies all of our needs. >> >> Since PHP allowed [] for strings, how about allow it, but deprecate it >> by doc in 7.1, deprecate(Raise error) it in 7.2, then remove it by >> 7.3? > > If anything then it can be removed by 8.
Good enough for me!
-- Yasuo Ohgaki yohgaki@ohgaki.net

Arvids Godjuks

10 years ago
On Mon, 15 Feb 2016 08:16 Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi all, > > On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev > <smalyshev@gmail.com> wrote: > >> 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. > > I fully agree {} and [] usage. > - {} only for string > - [] only for array > Simple is better if it satisfies all of our needs. > > Since PHP allowed [] for strings, how about allow it, but deprecate it > by doc in 7.1, deprecate(Raise error) it in 7.2, then remove it by > 7.3? > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > >
Hello, As a user-land developer I approve this message (with correction from Pierre that final removal should be in PHP 8 and keep it deprecated in PHP 7.1 by docs, 7.2 with a error message). Regards, Arvids Godjuks, Areto Development.

François Laupretre

10 years ago
Le 15/02/2016 04:49, Stanislav Malyshev a écrit :
> 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.
Right. Introducing a BC break in a minor version requires a consensus, and we should probably have discussed about it on the list, instead of github. So, let's discuss it further. As we probably agree that introducing a null byte in the string is a bug, what fix would you suggest ? If we consider the BC break too important for a minor version, another solution could be to consider an empty RHS string as a space character, because this is the padding char used when extending the string. There, we can keep almost the same behavior as the current one, except we put a space instead of a null byte and, maybe, raise an E_NOTICE. So, your example would cause $str to become "abc " instead of "abc \0" and the assignement would return " " instead of "\0". Regards François

Yasuo Ohgaki

10 years ago
Hi Francois, I noticed one issue on {} https://bugs.php.net/bug.php?id=71611 echo "${str{1}}"; raises syntax error while echo "{$str{1}}"; works. Is this addressed?
-- Yasuo Ohgaki yohgaki@ohgaki.net On Sun, Jan 24, 2016 at 12:45 AM, François Laupretre <francois@php.net> wrote:

François Laupretre

10 years ago
Hi, Le 17/02/2016 00:26, Yasuo Ohgaki a écrit :
> I noticed one issue on {} > https://bugs.php.net/bug.php?id=71611 > > echo "${str{1}}"; > > raises syntax error while > > echo "{$str{1}}"; > > works. Is this addressed?
No, this is a different problem. This RFC just adds support for negative index values. It does not deal with variable dereferencing using ${}/{$}. Regards François

Yasuo Ohgaki

10 years ago
On Wed, Feb 17, 2016 at 9:32 AM, François Laupretre <francois@php.net> wrote:
> > Le 17/02/2016 00:26, Yasuo Ohgaki a écrit : >> >> I noticed one issue on {} >> https://bugs.php.net/bug.php?id=71611 >> >> echo "${str{1}}"; >> >> raises syntax error while >> >> echo "{$str{1}}"; >> >> works. Is this addressed? > > > No, this is a different problem. This RFC just adds support for negative > index values. It does not deal with variable dereferencing using ${}/{$}.
Thank you. I filed new bug report for this. https://bugs.php.net/bug.php?id=71614 Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

François Laupretre

10 years ago
Hi, Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends Friday, March 4th 00:00 UTC. As, during the discussion, we talked about many related subjects, please remember that the subjects below remain out of scope of this RFC and deserve their own thread : - Support '{}/[]' on string offset assignments, - Reserve/recommand '{}' syntax for string offsets and '[]' for arrays, - Auto-conversion of empty string to array on string offset assignment, - the same with true/false, - support '++/--' on string offsets... Regards François

François Laupretre

10 years ago
Hi, (sorry, posting again with modified subject to force new thread) Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends Friday, March 4th 00:00 UTC. As, during the discussion, we talked about many related subjects, please remember that the subjects below remain out of scope of this RFC and deserve their own thread : - Support '{}/[]' on string offset assignments, - Reserve/recommand '{}' syntax for string offsets and '[]' for arrays, - Auto-conversion of empty string to array on string offset assignment, - the same with true/false, - support '++/--' on string offsets... Regards François

Andrew Faulds

10 years ago
Hi François, François Laupretre wrote:
> (sorry, posting again with modified subject to force new thread)
You might have to make yet another post. This last one had a new subject, but it still was marked as a reply, so my news client threads it in with the original thread. On a different note, have you considered writing a patch for the language specification to deal with negative offsets? Thanks!
-- Andrea Faulds https://ajf.me/

François Laupretre

10 years ago
Le 19/02/2016 00:48, Andrea Faulds a écrit :
> > You might have to make yet another post. This last one had a new > subject, but it still was marked as a reply, so my news client threads > it in with the original thread. >
Just posted the message once again. Still appears in the same thread. It seems Thunderbird is too smart for me :). Anyway, I'll post a reminder next week.
> On a different note, have you considered writing a patch for the > language specification to deal with negative offsets?
Right. Added to 'Open issues'. Thanks François

Pierre Joye

10 years ago
On Fri, Feb 19, 2016 at 7:33 AM, François Laupretre <francois@php.net> wrote:
> Le 19/02/2016 00:48, Andrea Faulds a écrit : >> >> >> You might have to make yet another post. This last one had a new >> subject, but it still was marked as a reply, so my news client threads >> it in with the original thread. >> > > Just posted the message once again. Still appears in the same thread. It > seems Thunderbird is too smart for me :). Anyway, I'll post a reminder next > week.
new mail, internals@.... That should do it :) Also a reminder is nice, a correct and visible vote start announce is a must. Please do it accordingly and the voting period will start when the mail announce is sent to the list :) Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

François Laupretre

10 years ago
Hi, Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends Friday, March 4th 00:00 UTC. As, during the discussion, we talked about many related subjects, please remember that the subjects below remain out of scope of this RFC and deserve their own thread : - Support '{}/[]' on string offset assignments, - Reserve/recommand '{}' syntax for string offsets and '[]' for arrays, - Auto-conversion of empty string to array on string offset assignment, - the same with true/false, - support '++/--' on string offsets... Regards François