Hi,
Starting discussion about https://wiki.php.net/rfc/negative-string-offsets
Please read and comment.
Regards
François
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/
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/
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
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
--
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
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
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
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
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
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
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 [].
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
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
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
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
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
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
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
raiseE_WARNINGfor 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
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
raiseE_WARNINGfor 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
Le 10/02/2016 15:34, Dan Ackroyd a écrit :
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
raiseE_WARNINGfor this kind of invalid assignments just likeFranç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
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
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]
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
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
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
Hi Stas,
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
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
Hi Stas,
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/consistentTo 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
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
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]
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; // zbcString 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
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]
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
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; // zbcString 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
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
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
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
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
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
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/
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
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
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
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
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.
Hi Pierre,
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
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.
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
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
Hi,
Starting discussion about https://wiki.php.net/rfc/negative-string-offsets
Please read and comment.
Regards
François
Hi,
Le 17/02/2016 00:26, Yasuo Ohgaki a écrit :
I noticed one issue on {}
https://bugs.php.net/bug.php?id=71611echo "${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
Le 17/02/2016 00:26, Yasuo Ohgaki a écrit :
I noticed one issue on {}
https://bugs.php.net/bug.php?id=71611echo "${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
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