Hi Ignace, Tim et al., I've finished updating the RFC once again, after some private discussion with Tim:
It turned out that the percent-decoding feature as proposed would have led to confusing behavior in some cases. In order to avoid this, I ultimately removed the percent-decoding support from the proposal. In the same time, I pivoted from the "instance methods on an enum” based approach to a simple namespaced function based solution, because the enums would only ever have a single method (even if decoding support is added later, possibly not all the (Uri|Url)PercentEncoder enum cases would be applicable for decoding). Let me know if this doesn't work for you, TBH adding namespaced functions was my least favorite solution, but I didn't have any significantly better idea which would have had the potential to gain traction. I have called out one example in the RFC ( https://wiki.php.net/rfc/uri_followup#percent-encoding_support) which would be problematic if we had a Uri\Rfc3986\uri_percent_decode() function, so let me copy-paste it here for reference: $uri = new Uri\Rfc3986\Uri("https://example.com/?a=b%26c";); // The query is the percent-encoded form of "a=b&c=d" echo Uri\Rfc3986\uri_percent_decode( $uri->getQuery(), Uri\Rfc3986\UriPercentEncodingMode::Query ); // a=b&c The result is probably not what we expected, because percent-decoding changed the meaning of the query component: - Originally, the query contained a parameter “a” with value “b%26c” (“b&c”) - Now, there is a parameter “a” with value “b”, as well as a parameter “c” without value And I'm now attempting once again to announce my intention to start the vote: If no significant issue comes up this time, then I'll start the vote next Tuesday evening (according to UTC). Regards, Máté
