François Laupretre wrote: > I need your thoughts on a PR (https://github.com/php/php-src/pull/1431) I am > working on. The subject is to change the way negative string offsets (and > lengths, where applicable) are handled, to make the behavior consistent with > the way they're handled in substr() and substr_replace(). If your return is > positive, I'll write the corresponding RFC. > > Implemented so far : > > - Support negative string offsets in read mode. Example: $a = $string{-2}; > > - Support negative string offsets in assignment mode. Example: $string{-2} = > 'z';
Generally, I like the idea of being able to specify negative string offsets. However, I'm usually working with UTF-8 strings, and as such I'm using string offsets rather seldom. > - strpos() : Accept negative values for the '$offset' argument > > - stripos() : Accept negative values for the '$offset' argument > > - substr_count(): Accept negative values for the '$offset' and '$length' > parameters (same behavior as in substr()). That may be useful as well, but what about the respective mbstring and grapheme functions? At least these should be improved as well, but I'm not sure if that can be done in an efficient manner. > I also have some questions : > > - Should we keep returning NULL on parameter parsing failure, while > documentation only states that false is returned on failure ? It is documented[1] that: | If the parameters given to a function are not what it expects, such | as passing an array where a string is expected, the return value of | the function is undefined. In this case it will likely return NULL | but this is just a convention, and cannot be relied upon. IMHO it's best to stick with the current behavior, and to consider to raise exceptions sometime in the future. [1] <http://php.net/manual/en/functions.internal.php> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
