Re: [RFC] Consistent null behaviour

Am 20.09.2017 um 19:23 schrieb ilija.tovilo@me.com:

I realized after sending the initial E-Mail that there might be more breaking changes than I thought, like the one you suggested. The same thing actually happens for bools, ints and floats: https://3v4l.org/jvVbO I wouldn’t depend on this behaviour since you’d get errors depending on what is returned, like an empty array, a string, an object or resource.

i would depend on that behavior because in reality you can get back two different things: * a numeric array with exactly index 0 * NULL how do you imagine mysqli_fetch_row() return empty array, string or even object/resource? when nothing is found it's a non-empty array and otherwise NULL before PHP 5.6 (or PHP 5.5 not sure) these where useless multiple lines because you needed to store the result of mysqli_fetch_row() in some var to access key 0

On 20 Sep 2017, 19:18 +0200, lists@rhsoft.net <lists@rhsoft.net>, wrote:

Am 20.09.2017 um 19:06 schrieb ilija.tovilo@me.com:

Hi everybody! To my surprise, I noticed today that an array access on a null value returns null without any warning whatsoever. Accessing the property of a null value gives you a notice, while calling a function on that null value gives you a fatal error. https://3v4l.org/ZSZHN This is pretty inconsistent. IMO all of these should be fatal errors, although I realize that might be a bit drastic for PHP 8. We should at least give the user a notice when using array access on a null value. Any thoughts?

wouldn't that break code like below which is IMHO the best usecase of the PHP 5.6 feature that you can directly access a array field of a function result and the type-casting encsues that the return-type is always int function GetSKatMaxSort(int $archive=0): int { return (int)mysqli_fetch_row($this->db->query("select SQL_NO_CACHE max(ssort) from {$this->db->table} where sarchive=$archive", 1))[0]; }