Hi Kamil Tekiela, I read your RFC and I understand the intent in improving the current parse_str function behaviour by introducing a new function to avoid possible breakage, However I feel that we are missing a chance to also improve how parse_str algorithm is currently used, we could or should (?) use this opportunity to fix some long shortcomings around parse_str.
In no particular order: parse_str mangled data while it was acceptable before when it could directly inject PHP variables into the current scope, this feature is no longer needed and prevents interoperability with other query parsing algorithms used in other languages. Also since this mangled data is not well known it comes as a surprise to average PHP developer as the behaviour feels unexpected see https://3v4l.org/KIJ9V parse_str assumes that the query separator is always a "&" which reduces its usage to only parsing query using that particular character. Again this might be seen as an edge case but no RFC prevents using any other character. If you where to use another character you are bound to use some userland code workaround to then feed the "normalized" string to parse_str parse_str parse the query string using PHP algorithm while there are now some established parsing algorithm that are languages independant like https://url.spec.whatwg.org/#interface-urlsearchparams that defines how a query string should be parsed. If we were to introduce your function as is, I feel that we will have to submit yet another RFC and have a language with at least two ways to parse a string. So maybe instead of a new function what we need is an object with a better public API ? thoughts
