Warning for Implicit URL-String Comparisons

[xwu (Xiaodi Wu)]

@thepearl

You mentioned that 'not transitively exporting extensions' could be a potential solution if the library author properly modularizes their internal retroactive conformances. Could you elaborate on this approach? Is there a specific pitch or proposal for this feature that I could look into?

I was thinking about this pitch, if the author of LibraryA separates their conformance into a LibraryARetroactiveConformances module, then imports that into their own code without using @_exported to re-export to you.

@thepearl

Also, as a developer using such a library, what would be the best practice to handle this situation in my code? Should I simply be more explicit in my use of URL and avoid relying on the problematic conformance, or are there other strategies you'd recommend?

Just the options @Jumhyn writes, I'm afraid: live with it, fork it, or don't use it. Because the API here is implicitly invoked, it'll be hard to just avoid because it's not something you can easily lint against, though.

A retroactive conformance of a type you don't own to a protocol you don't own, which provides implicit functionality, that is exported to clients is close to the supreme example of what should not be done and you've found it.