FWIW we've overridden URL's equality function in order to get a "more realistic"
result. We lowercase everything and compare the scheme, host, port, and query,
along with normalizing the path to handle cases where `/` exists in some paths
but doesn't in others. This solves this problem as well:
1> import Foundation
2> let a = URL(string: "apple.com")
a: URL? = "apple.com"
3> let b = URL(string: "apple.com/")
b: URL? = "apple.com/"
4> a == b
$R0: Bool = false
Note that if you do this, you have to define the `==` operator for URL in an
extension in the same module you plan to use it, otherwise you end up with some
On 10/15, Zhao Xin via swift-users wrote:
> You are right Jens. If I use `appendingPathComponent`, it works.
> let url = URL(fileURLWithPath: "foo/bar", isDirectory: false)
> let baseURL = url.deletingLastPathComponent()
> let newURL = URL(fileURLWithPath: "bar", isDirectory: false, relativeTo:
> let testURL = baseURL.appendingPathComponent("bar")
> print(url == newURL) // prints false
> print(url.path == newURL.path) // prints true
> print(url == testURL) // prints true
> print(url.path == testURL.path) // prints true
> On Sat, Oct 15, 2016 at 11:19 AM, Jens Alfke <j...@mooseyard.com> wrote:
> > > On Oct 14, 2016, at 5:16 PM, zh ao via swift-users <
> > firstname.lastname@example.org> wrote:
> > >
> > > In your opinion, `baseURL` is a factor more important than `path`. I can
> > not unaccept your answer. But I want to know why? Is there a standard on
> > URL equality?
> > I think this is just a weirdness of NSURL (assuming you’re running this
> > code on macOS or iOS.) I’ve always avoided the `relativeTo:` initializers
> > of NSURL because the objects they produce behave (IMHO) unexpectedly.
> > —Jens
> swift-users mailing list
swift-users mailing list