Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistencyThanks. Dmitry.
Since in the "should people be allowed to vote" thread, I said I think
people should explain their votes, here is my explanation :)
I am voting disable. +1 for consistency, but I think we already have a
pretty rich suite of functions for working with strings that do not
work with arrays, and vice versa. I think enabling list() to work on
strings sets a precedent that more/all array handling mechanisms
should be made to work with strings, and I'm not sure that's something
we want.
We've defined list as not working with strings in the manual, lets
stick to our own definition.
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a lot. :)
enabling string handling would require complication of
ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
It's going to make list() handling a bit slower, but not significantly.
my choice +1 for disabling.
Thank. Dmitry.
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistencyThanks. Dmitry.
Since in the "should people be allowed to vote" thread, I said I think
people should explain their votes, here is my explanation :)I am voting disable. +1 for consistency, but I think we already have a
pretty rich suite of functions for working with strings that do not
work with arrays, and vice versa. I think enabling list() to work on
strings sets a precedent that more/all array handling mechanisms
should be made to work with strings, and I'm not sure that's something
we want.We've defined list as not working with strings in the manual, lets
stick to our own definition.
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a lot.
:)enabling string handling would require complication of
ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
It's going to make list() handling a bit slower, but not significantly.my choice +1 for disabling.
Could you please clarify why removing string support would make the
operation simpler? I voted for always supporting strings because I thought
that is the option that simplifies things - in particular it would allow
use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R
instead. Sample patch here:
https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I miss
something and we can't do that?
Nikita
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a lot.
:)enabling string handling would require complication of
ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
It's going to make list() handling a bit slower, but not significantly.my choice +1 for disabling.
Could you please clarify why removing string support would make the
operation simpler? I voted for always supporting strings because I thought
that is the option that simplifies things - in particular it would allow
use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R
instead. Sample patch here:
https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I
miss something and we can't do that?Nikita
I'd like to add that the FETCH_DIM_TMP_VAR opcode also provides incorrect
results if objects are used. list() generally accepts objects implementing
ArrayAccess, but if the object happens to be a TMP_VAR and
FETCH_DIM_TMP_VAR is used instead of FETCH_DIM_R, you'll just get a NULL
result:
<?php
class Arr implements ArrayAccess {
private $arr;
public function offsetGet($k) { return $this->arr[$k]; }
public function offsetSet($k, $v) { $this->arr[$k] = $v; }
public function offsetExists($k) { return isset($this->arr[$k]); }
public function offsetUnset($k) { unset($this->arr[$k]); }
}
$arr = new Arr;
$arr[0] = 'foo';
$arr[1] = 'bar';
list($a, $b) = $arr;
var_dump($a, $b); // foo, bar
// (object) forces TMP_VAR
list($a, $b) = (object) $arr;
var_dump($a, $b); // NULL, NULL
So to handle that case we'd already have to extend the FETCH_DIM_TMP_VAR
handler to support objects in addition to arrays. At which point I don't
really see the point of making this a special case and would always use
FETCH_DIM_R instead (which already has all the necessary code to support
arrays, objects and strings).
Nikita
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov nikita.ppv@gmail.com
wrote:disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a
lot. :)enabling string handling would require complication of
ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
It's going to make list() handling a bit slower, but not significantly.my choice +1 for disabling.
Could you please clarify why removing string support would make the
operation simpler? I voted for always supporting strings because I thought
that is the option that simplifies things - in particular it would allow
use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R
instead. Sample patch here:
https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I
miss something and we can't do that?Nikita
I'd like to add that the FETCH_DIM_TMP_VAR opcode also provides incorrect
results if objects are used. list() generally accepts objects implementing
ArrayAccess, but if the object happens to be a TMP_VAR and
FETCH_DIM_TMP_VAR is used instead of FETCH_DIM_R, you'll just get aNULL
result:<?php
class Arr implements ArrayAccess {
private $arr;
public function offsetGet($k) { return $this->arr[$k]; }
public function offsetSet($k, $v) { $this->arr[$k] = $v; }
public function offsetExists($k) { return isset($this->arr[$k]); }
public function offsetUnset($k) { unset($this->arr[$k]); }
}$arr = new Arr;
$arr[0] = 'foo';
$arr[1] = 'bar';list($a, $b) = $arr;
var_dump($a, $b); // foo, bar// (object) forces TMP_VAR
list($a, $b) = (object) $arr;
var_dump($a, $b); // NULL,NULLSo to handle that case we'd already have to extend the FETCH_DIM_TMP_VAR
handler to support objects in addition to arrays. At which point I don't
really see the point of making this a special case and would always use
FETCH_DIM_R instead (which already has all the necessary code to support
arrays, objects and strings).Nikita
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?
Why do array_* functions not treat strings as arrays of bytes?
If we we can/want to make strings byte arrays, then I am 100% in
favour of all array operations working on strings. If this is
something we want to work towards for the future, that's great, lets
get busy :) - If we want to say "yea list() should work with strings",
but no other array functions should work with strings, it seems very
odd to me.
Hi!
Why do array_* functions not treat strings as arrays of bytes?
How that's related? We're not talking about array_* functions, we're
talking about list() operator.
get busy :) - If we want to say "yea list() should work with strings",
but no other array functions should work with strings, it seems very
odd to me.
It's as odd as [] working with strings but -> not. Those are different
things, so they work differently.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
It's as odd as [] working with strings but -> not. Those are different
things, so they work differently.
Sorry, this was kind of my point, I probably just phrased it badly.
The array_* "question" was meant to be rhetorical.
My points are:
- Strings are not treated as arrays of bytes everywhere.
- If we intend to give strings more array-like support after this RFC
(like foreach($string as $char), making array_* work with strings),
then I support the list() change. - Otherwise not
Hi!
- Strings are not treated as arrays of bytes everywhere.
This is true. However, sometimes they are. E.g., $string[0] is
meaningful, while array_flip($string) is not.
- If we intend to give strings more array-like support after this RFC
We don't intend to give strings anything - both $string[0] and list($a,
$b) = $string works right now. See here: http://3v4l.org/7AZFZ
So you are arguing for BC break for no reason at all.
(like foreach($string as $char), making array_* work with strings),
Nobody proposed that in this RFC, and it makes zero sense to propose it
in this RFC, as this RFC is about list(), not about making strings into
arrays which would require humongous amount of work and was not
requested by anybody.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
It's an inconsistent undocumented behavior, that started to work not by
design, but because of implementation issues.
<?php
list($a, $b) = "ab";
var_dump($a,$b);
?>
NULL NULL
By the way, I'm agree, keeping string support might be better for
compatibility.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 11:16 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
- Strings are not treated as arrays of bytes everywhere.
This is true. However, sometimes they are. E.g., $string[0] is
meaningful, while array_flip($string) is not.
- If we intend to give strings more array-like support after this RFC
We don't intend to give strings anything - both $string[0] and list($a,
$b) = $string works right now. See here: http://3v4l.org/7AZFZSo you are arguing for BC break for no reason at all.
(like foreach($string as $char), making array_* work with strings),
Nobody proposed that in this RFC, and it makes zero sense to propose it
in this RFC, as this RFC is about list(), not about making strings into
arrays which would require humongous amount of work and was not
requested by anybody.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
My points are:
- Strings are not treated as arrays of bytes everywhere.
- If we intend to give strings more array-like support after this RFC
(like foreach($string as $char), making array_* work with strings),
then I support the list() change.- Otherwise not
At what point does is_array(string) = true?
That is my 'interpretation' of $a[?] over $a where $a is a string.
So the statement 'Disable string handling in all cases' is simply wrong
since $a[0] is NOT a string but is working perfectly as designed. It
would be inconsistent to now treat the array $a[0] as if it wasn't an array.
--
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
On Thu, Sep 25, 2014 at 11:50 PM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?
That's exactly what list() does. The only catch is that $foo here is reused
multiple times and mustn't be freed in the meantime (for the cases where
$foo is some complex expression resulting in an VAR or TMP_VAR operand).
That's what the ZEND_FETCH_ADD_LOCK flags for FETCH_DIM_R does - it does
$foo[0] without freeing $foo.
However back when list() was introduced FETCH_DIM_R didn't support CONST or
TMP_VAR operands, so instead these two used a separate FETCH_DIM_TMP_VAR
opcode, which supports only arrays and not strings or objects. Support for
CONST|TMP in FETCH_DIM_R was only added in PHP 5.5 as part of constant
string/array dereferencing.
Long story short, because FETCH_DIM_R now supports CONST and TMP_VAR
operands, we can always use it and FETCH_DIM_TMP_VAR can be dropped -
that's all that has to be done in order to always support strings and
objects in list(). (I've linked a patch for this previously, see
https://github.com/nikic/php-src/compare/stringOffsetsInList).
If I understood it correctly, then Dmitry's alternative is to add support
for CV and VAR operands to FETCH_DIM_TMP_VAR and always use that for
list(). This avoids having to check the ZEND_FETCH_ADD_LOCK flag in
FETCH_DIM_R. However I don't think that this optimization is related to
whether or not we support strings and objects. We can have a separate
opcode only for list() in either case, no matter which choice is made here.
Nikita
Hi!
Long story short, because FETCH_DIM_R now supports CONST and TMP_VAR
operands, we can always use it and FETCH_DIM_TMP_VAR can be dropped -
that's all that has to be done in order to always support strings and
objects in list(). (I've linked a patch for this previously, see
https://github.com/nikic/php-src/compare/stringOffsetsInList).
Excellent, IMO this is the most logical way to proceed - and I'm not
sure why one check for one flag is something worth worrying about. Is it
really that slow to check for one flag?
If I understood it correctly, then Dmitry's alternative is to add
support for CV and VAR operands to FETCH_DIM_TMP_VAR and always use that
for list(). This avoids having to check the ZEND_FETCH_ADD_LOCK flag in
FETCH_DIM_R. However I don't think that this optimization is related to
whether or not we support strings and objects. We can have a separate
opcode only for list() in either case, no matter which choice is made here.
We can, of course, but with your explanation I don't really see why we
even should...
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.
It's not complicated to change it in any way.
The question which way is better, and it's the reason of voting.
I would prefer not to extend list() to support strings, but in case
"enabling" would win, I'll make it.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hey:
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.It's not complicated to change it in any way.
The question which way is better, and it's the reason of voting.I would prefer not to extend list() to support strings, but in case
"enabling" would win, I'll make it.Thanks. Dmitry.
I am working what should we do if none side get 2/3 votes?
it seems it is going there :<
thanks
On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.It's not complicated to change it in any way.
The question which way is better, and it's the reason of voting.I would prefer not to extend list() to support strings, but in case
"enabling" would win, I'll make it.Thanks. Dmitry.
I am working what should we do if none side get 2/3 votes?
worrying
it seems it is going there :<
thanks
On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Simple majority between second and third options will win,
Thanks. Dmitry.
Hey:
I told it doesn't support strings and objects because it was designed
this
way.
I don't know who and when did it.It's not complicated to change it in any way.
The question which way is better, and it's the reason of voting.I would prefer not to extend list() to support strings, but in case
"enabling" would win, I'll make it.Thanks. Dmitry.
I am working what should we do if none side get 2/3 votes?
worryingit seems it is going there :<
thanks
On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/--
Xinchen Hui
@Laruence
http://www.laruence.com/--
Xinchen Hui
@Laruence
http://www.laruence.com/
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
So, just to clarify: If we vote to "remove string handling in all cases"
does that also mean that we "remove ArrayAccess support in all cases"? If
so, could the RFC please explicitly mention that?
Nikita
When I started this RFC I didn't thought about objects.
Actually, they are handled with the same inconsistency problem.
Nikita, feel free to add this note to RFC.
May be it'll change mind of some voters :)
also add a link to your patch.
Thanks. Dmitry.
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
So, just to clarify: If we vote to "remove string handling in all cases"
does that also mean that we "remove ArrayAccess support in all cases"? If
so, could the RFC please explicitly mention that?Nikita
When I started this RFC I didn't thought about objects.
Actually, they are handled with the same inconsistency problem.Nikita, feel free to add this note to RFC.
May be it'll change mind of some voters :)also add a link to your patch.
Please do not :) Enough mess with RFC changed while being voting on.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
When I started this RFC I didn't thought about objects.
Actually, they are handled with the same inconsistency problem.Nikita, feel free to add this note to RFC.
May be it'll change mind of some voters :)also add a link to your patch.
Please do not :) Enough mess with RFC changed while being voting on.
Yeah, that’s a pretty big change. I wouldn’t vote how I did if it meant affecting ArrayAccess. Please restart the vote.
Andrea Faulds
http://ajf.me/
nothing was changed in RFC itself, just additional details were clarified
during discussion.
I didn't thought about ArrayAccess when found this inconsistency.
Anyway, I won't object if someone will add missing info about ArrayAccess
support inconsistency and restart the voting.
Thanks. Dmitry.
When I started this RFC I didn't thought about objects.
Actually, they are handled with the same inconsistency problem.Nikita, feel free to add this note to RFC.
May be it'll change mind of some voters :)also add a link to your patch.
Please do not :) Enough mess with RFC changed while being voting on.
Yeah, that’s a pretty big change. I wouldn’t vote how I did if it meant
affecting ArrayAccess. Please restart the vote.Andrea Faulds
http://ajf.me/
So, just to clarify: If we vote to "remove string handling in all cases"
does that also mean that we "remove ArrayAccess support in all cases"? If
so, could the RFC please explicitly mention that?
I myself would be in favour of removing string support, but I don’t want to remove ArrayAccess. There’s no good reason to get rid of it.
Andrea Faulds
http://ajf.me/
just change your vote.
I just did it. :)
Even if ArrayAccess worked not by design, it's going to be a big
compatibility issue, removing it.
Strings support would work for free.
Thanks. Dmitry,
So, just to clarify: If we vote to "remove string handling in all cases"
does that also mean that we "remove ArrayAccess support in all cases"? If
so, could the RFC please explicitly mention that?I myself would be in favour of removing string support, but I don’t want
to remove ArrayAccess. There’s no good reason to get rid of it.Andrea Faulds
http://ajf.me/
just change your vote.
I just did it. :)Even if ArrayAccess worked not by design, it's going to be a big compatibility issue, removing it.
Strings support would work for free.
What should I vote then? I want to vote against string support, but in favour ArrayAccess support.
--
Andrea Faulds
http://ajf.me/
FETCH_DIM_TMP_VAR is used especiualy for list().
It expects array, don't check for objects and strings.
It doesn't remove the operand and allow it's reuse in next opcode.
FETCH_DIM_R is used for list() only in some cases (when operand IS_VAR).
To work in list() context it has to keep operand not destroyed, and to do
it FETCH_DIM_R has to check for (opline->extended_value &
ZEND_FETCH_ADD_LOCK).
Note that this check has to be executed for each array access operation
unrelated to list() handling.
Thanks. Dmitry.
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a lot.
:)enabling string handling would require complication of
ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
It's going to make list() handling a bit slower, but not significantly.my choice +1 for disabling.
Could you please clarify why removing string support would make the
operation simpler? I voted for always supporting strings because I thought
that is the option that simplifies things - in particular it would allow
use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R
instead. Sample patch here:
https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I
miss something and we can't do that?Nikita
2014-09-25 9:42 GMT+02:00 Dmitry Stogov dmitry@zend.com:
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistencyThanks. Dmitry.
Hi,
I'm in favor of disabling for consistency as well, however, I wish a
warning would be emitted.
Not only it would tell me that I have a potential error while upgrading to
PHP 7 but also if I am using it incorrectly, which is always the case when
using a scalar value.
I therefor propose that:
list($a, $b) = 42;
list($a, $b) = "42";
list($a, $b) = null;
...
generates a warning like: PHP Warning: list() expects right operand to be
array, <type> given in <path> on line <line>
Currently, all of the above lines wouldn't generate any notice / warning /
error, however, using:
list($a, $b) = [];
generates the following notices:
PHP Notice: Undefined offset: 1 in ... on line ...
PHP Notice: Undefined offset: 0 in ... on line ...
This is confusing since (to me) using an array is at least better than
using scalars.
Patrick
Hi everyone,
[...]
I'm in favor of disabling for consistency as well, however, I wish a
warning would be emitted.
Voted in favour of disabling as well but could easily live with the other option as everything is better then leaving the inconsistency there.
cu,
Lars
[...]
I'm in favor of disabling for consistency as well, however, I wish a
warning would be emitted.Voted in favour of disabling as well but could easily live with the
other option as everything is better then leaving the inconsistency
there.
So you'd rather have that already working code now stops working,
instead of new bits of code starting to work. That's incredibly
backwards.
Certainly it would be less of a pain for our users to allow both options‽
cheers,
Derick
2014-09-25 17:27 GMT+02:00 Patrick ALLAERT patrickallaert@php.net:
2014-09-25 9:42 GMT+02:00 Dmitry Stogov dmitry@zend.com:
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistencyThanks. Dmitry.
Hi,
I'm in favor of disabling for consistency as well, however, I wish a
warning would be emitted.
Not only it would tell me that I have a potential error while upgrading to
PHP 7 but also if I am using it incorrectly, which is always the case when
using a scalar value.I therefor propose that:
list($a, $b) = 42;
list($a, $b) = "42";
list($a, $b) = null;
...
generates a warning like: PHP Warning: list() expects right operand to be
array, <type> given in <path> on line <line>Currently, all of the above lines wouldn't generate any notice / warning /
error, however, using:
list($a, $b) = [];generates the following notices:
PHP Notice: Undefined offset: 1 in ... on line ...
PHP Notice: Undefined offset: 0 in ... on line ...This is confusing since (to me) using an array is at least better than
using scalars.Patrick
bump ?
(It is ok to say it's a stupid idea or that I just don't know what I am
talking about)
Patrick
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Voted +1 for disabling.
I think string handling needs more thorough designing and planning for
edge case and such; i.e. the string handling alternative seems to rushed
to me thus I err on the cautious side.
thank you,
- Markus
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistencyThanks. Dmitry.
Voting for always disabling string handling. This behavior is arcane and weird to me, and can be quickly emulated with list($a,$b) = str_split([“ab”][0]); if someone was actually using it.
-- Gwynne Raskind
Hi!
and weird to me, and can be quickly emulated with list($a,$b) =
str_split([“ab”][0]); if someone was actually using it.
BC breaks don't work this way. When somebody's code would break on PHP
7, their first move would not be "oh, great, let's refactor it, it was
too arcane anyway". It would be "OK, let's postpone the upgrade to
$current_year + 5".
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistencyThanks. Dmitry.
Voting for always disabling string handling. This behavior is arcane and weird to me, and can be quickly emulated with list($a,$b) = str_split([“ab”][0]); if someone was actually using it.
-- Gwynne Raskind
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistencyThanks. Dmitry.
Hi,
After discussing this RFC with a few other members of AFUP (French UG),
we agree something should be done, to get to a consistent behavior:
either all, or nothing, but not half.
Most of us seem to go towards "disabling in all cases" (which indeed
means BC-break for those who were using this -- probably not that many),
but it seems like no-one will be sad if things end up going the other
way around.
--
Pascal MARTIN
http://blog.pascal-martin.fr/
@pascal_martin