Drop CF dependency

[karwa]

I noticed that this library uses CoreFoundation directly. IIRC that is not portable; CF is available on Darwin platforms and Linux, but is deliberately omitted from other platforms (e.g. Windows).

CoreFoundation is not meant to be public, and the Windows port has generally been far more aggressive about preventing leakage of internal interfaces and encouraging cross-compilation.

See discussion on the Swift forums announcement thread. Basically, Foundation doesn't (yet) provide the APIs this library needs. There may be ways around it, but that discussion is probably better to have here than on the forums.

[guoye-zhang]

This is load-bearing code, therefore we need to fully understand the changes necessary before making the switch.

There is an ongoing to effort to reimplement URL in Swift, and this will be one of the top issues to figure out.

[karwa]

Sure.

For creation, we have: NSURL(absoluteURLWithDataRepresentation:relativeTo:), whose implementation forwards to the same CFURL function that is currently used.

NSURL(absoluteURLWithDataRepresentation: Data("https://example.com?q=1|2".utf8), relativeTo: nil) as URL
$R34: Foundation.URL = "https://example.com?q=1|2"
                                               ^

The goal of this issue is only to avoid direct uses of CoreFoundation, because it is supposed to be a private implementation detail of Foundation. While some of the earlier supported platforms (Darwin-family, Linux) allow it to be imported anyway, on newer platforms (Windows, Wasi), import CoreFoundation will fail.

I haven't found a way to get the path and query exactly as they are in a URL (without running them through another percent-encoding pass) - although, as I mentioned on the forums, other APIs such as .host(percentEncoded: true) do offer exact values. We can add API to Foundation to expose that information, or we can suggest changing the implementation of .path(percentEncoded: true) so that it behaves consistently with .host(percentEncoded:) and omits its additional encoding pass (and we can then immediately implement it in corelibs-foundation).

As for reimplementing URL in Swift, I believe the goal is to preserve the existing API. I've tried to reach out to the Foundation team regarding URL as I have some expertise in that area but, as with every other time I've tried to reach out over the years, have been completely ignored. I don't see any indication that a major URL rewrite with significant API changes is imminent from Foundation, and in terms of this library I have suggested some more promising, actionable alternatives above.

[guoye-zhang]

I'm not in the position to decide URL behavior. We will raise this issue and your proposal with Foundation team and people responsible for URL, but this package is not the only one depending on a particular URL behavior. An API as old as NSURL has rough edges from the bug fixes and compatibility workarounds gathered over the years so I would understand the hesitancy to change the behavior. Introducing a new WHATWG mode or a new API might be the only viable way forward.

In the meantime if Windows support is desired, a possible workaround is to call url.absoluteURL.dataRepresentation and parse it manually into individual components.