FYI, I've just landed the initial implementation of WebURL -> Foundation.URL conversion on the main branch.
It still needs more tests and fuzzing before I'm happy to tag a release with it, but so far I've been testing it against the web-platform-tests (the shared test suite used by the major browsers). Because WebURL is automatically normalized, for the most part, it can just be parsed by Foundation and everything is fine.
Percent-Encoding
The most significant area where we actually need to do something is when the URL contains technically-invalid characters like square brackets or curly braces, for example:
"http://example.com/foo?color[R]=100&color[G]=230&color[B]=123"
"http://example.com/products?id={uuid}"
These kinds of URLs are indeed in use on the web (for example, JSONAPI and OpenAPI use square brackets to reference an objects in a graph). Even though these characters are technically invalid, the WHATWG URL Standard requires that we allow them, even without percent-encoding - and all the major browsers do that. But Foundation.URL is very strict and doesn't allow them. It's actually quite inconsistent - it accepts strings with square brackets and percent-encodes them, but rejects curly braces and other characters.
Now, percent-encoding is a tricky business. The server has complete freedom to treat a URL however it likes, so in the most general case we can't say for sure when percent-encoding would alter how the URL is processed. If a server sees "color%5BR%5D", we can't guarantee that it won't interpret that as an object literally named "color[R]" rather than a reference to a sub-object. It's all just application-level semantics; you can even invent your own ways of encoding additional structure if you need it.
Given that we don't know what is safe to encode or not, the safest thing to do is to send the URL as it was written, and if you use something like our async-http-client port to make the request directly from WebURL, that is what will happen (matching Safari, Firefox, and Chrome). But if you make the request via URL and URLSession, those characters need to be percent-encoded.
So the conversion initializer offers to percent-encode those characters for you. The default is true, because it's probably fine (?) for most servers, but if you encounter a situation where a server treats encoded and non-encoded characters differently, you can opt-out of it. Unfortunately, opting-out means the conversion will fail if disallowed characters are present, because URL just will not accept it.
Results
With encoding enabled (again, the default), we can convert 650/666 tests in the WPT suite (97.6%), and even without encoding, 93.7% of them pass. And this is a URL test suite, so it includes a lot more weird URLs than most users are likely to ever encounter.
So yeah, that's a quick update. Do please try it out and let me know if you have any issues. I know URLSession is critical for network requests on Apple platforms, and now you can WebURL throughout your application - right up to the point where you make the request.
I'm also looking in to wrapping some Foundation APIs so you won't need to manually convert URL types. But that's a little way off because I'd ideally like to propagate the original WebURL through to the URLResponse. I'm looking at a couple of cheeky tricks which could allow that ;)
