From the URLComponents documentation:
This structure parses and constructs URLs according to RFC 3986. Its behavior differs subtly from that of the URL structure, which conforms to older RFCs. However, you can easily obtain a URL value based on the contents of a URLComponents value or vice versa.
Of course I understand why
NSURL's implementation is stuck using older RFCs—there's legacy Cocoa code going all the way back to 2001 (or maybe even earlier) that relies on the old behavior, and that we can't break. But does that really apply to the Swift
URL struct? At least conceptually, the Swift value types are a clean break from their Objective-C counterparts in many ways, particularly in the
String type and the substantially different way it treats characters, indices and ranges. Therefore, doesn't it make more sense for our
URL struct to use the most current RFCs available to us in initialization, by using
-initWithString: method as the backing instead of
NSURL's? For those who truly need the older RFC, the
NSURL class is still available to Swift and easily bridgeable to
As things stand currently, it seems to me, given the documentation, that
URLComponents(string:)?.url is a more "correct" way to create a URL than
URL(string:), but I've almost never seen anyone actually use it, to the point that I've actually received confused comments in the past from high-reputation users on Stack Overflow for using it in answers instead of
The work to change the implementation would be trivial, should we decide to do it.
What do you think?