Re: [RFC] Generalize support of negative string offsets

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