Hi Màté, I read the Accessing Path Segments as an Array sub RFC and I have a couple of remarks, suggestions. In the RFC text it is said that:
> The getter methods return null if the path is empty (https://example.com), an empty array when the path > consists of a single slash (https://example.com/), and a non-empty array otherwise. This is suboptimal to me because it means that the signature for the getter methods is `array|null` which would lead developers to always add a check in the code whenever using the method to distinguish the path state absolute or not. Instead, I would rather always get a single type, the array as return value. The issue you are facing is that you want to convey via your return type if the path is absolute or not. But, we already have access to this information via the UriType Enum, at least in the case of the Uri\Rfc3986\Uri class. For the Uri\WhatWg\Uri the information is less crucial as the validation and normalization rules of the WHATWG specifications will autocorrect the path if needed. This leads me to propose the following alternative: For Uri\Rfc3986\Uri: ``` /** @return list<string> */ Uri::getPathSegments(): array {} /** @return list<string> */ Uri::getRawPathSegments(): array {} #[\NoDiscard(message: "as Uri\Rfc3986\Uri::withPathSegments() does not modify the object itself")] Uri::withPathSegments(array $segments, Uri\Rfc3986\UriType $uriType = Uri\Rfc3986\UriType::RelativePathReference): static {} ``` (the default value for the `$uriType` parameter is TBD). For Uri\WhatWg\Url: ``` /** @return list<string> */ Url::getPathSegments(): array {} #[\NoDiscard(message: "as Uri\WhatWg\Url::withPathSegments() does not modify the object itself")] /** @param list<UrlValidationError> $errors */ Url::withPathSegments(array $segments): static {} ``` with the following behaviour *The getter methods return the empty array if the path is empty (https://example.com <https://example.com>), or a single slash (https://example.com/ <https://example.com/>),and a non-empty array otherwise.* To distinguish between an absolute path and a relative path you can refer to the Uri\Rfc3986\Uri::getUriType(), method, in case of RFC 3986 URI, and the information does not matter otherwise (ie: for WHATWG URL). During update, for RFC 3986 URI, The additional `$uriType` argument would serve to tell if a `/` should be prepended or not to the generated string path. For the WHATWG URL, no soft errors are emitted, which show that the starting slash does not really matter. Best regards, Ignace On Mon, Dec 1, 2025 at 9:53 PM Máté Kocsis <[email protected]> wrote: > Hi Everyone, > > I'd like to introduce my latest RFC that I've been working on for a while > now: https://wiki.php.net/rfc/uri_followup. > > It proposes 5 followup improvements for ext/uri in the following areas: > - URI Building > - Query Parameter Manipulation > - Accessing Path Segments as an Array > - Host Type Detection > - URI Type Detection > - Percent-Encoding and Decoding Support > > I did my best to write an RFC that was at least as extensive as > https://wiki.php.net/rfc/url_parsing_api had become by the end. Despite > my efforts, > there are still a couple things which need a final decision, or which > need to be polished/improved. Some examples: > > - How to support array/object values for constructing query strings? ( > https://wiki.php.net/rfc/uri_followup#type_support) > - How to make the UriQueryParams and UrlQueryParams classes more > interoperable with the query string component (mainly with respect to > percent-encoding)? ( > https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding) > - Exactly how the advanced percent-decoding capabilities should work? Does > it make sense to support all the possible modes (UriPercentEncodingMode) > for percent-decoding as well ( > https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding_support > ) > - etc. > > Regards, > Máté >
