Hi Máté, I just re-read the RFC and I like the updates and precision you've brought to it here's my review: For the builders I have nothing more design wise to add this is already solid. I may nitpick on the *Builder::clear() method name I would have gone with *Builder::reset() but I presume other developers would go with clear. Other than that the public API is spot on.
For the Enum, my only concern is that they serve just as flags and their usage is tightly coupled to the Uri classes. I would add 2 static named constructors fromUrl and tryFromUrl just for completeness. I believe the maintenance cost is negligible but the developer DX is improved and allows for a broader usage of the Enum. In regards to the path segments usage and constructor I see you already integrate my Enum suggestions and you have explained why a fully fledged class is not the right approach. So the current design is already solid. Last but not least, The Percent encoding feature should be IMHO improved by moving the encode/decode methods from being static methods on the URI classes to becoming public API on the Enum. This would indeed imply renaming the enum from Uri\Rfc3986\UriPercentEncodingMode to Uri\Rfc3986\UriPercentEncoder with two methods encode/decode. Again it makes for a more self-contained feature and adds to the DX. Developer will not have to always statically call the URI classes for encoding/decoding strings as the Enums and their cases already convey the information correctly. Overall I believe this is going into the right direction Regards, Ignace On Sun, Mar 1, 2026 at 11:09 PM Máté Kocsis <[email protected]> wrote: > Hey Ignace et al, > > I have updated the RFC in the past few weeks with a lot of extra info, > mostly related to path segment handling: I investigated WHATWG URL's > behavior more thoroughly, and it turned out that path segments are handled > very interestingly, so there was a significant difference compared > to RFC 3986 yet again. > > Please give the RFC another read, if possible. > > Regards, > Máté > >
