To make sure you are aware, as described in Conditional conformance collisions, Basic's change to conform Range to Codable is problematic for clients that do the same thing. SourceKit-LSP already updated its code to avoid this problem, but you may want to do the same.
Sigh, I'll remove the conformance from SwiftPM. It's a bit unfortunate that we can't really create extensions on stdlib types 
Do we really need to remove it? These kind of issues aren't new or specific to SwiftPM, but I'm not sure if removing them is the right solution. @jrose, are my misremembering but have you already thought/posted about this in the past?
As the Swift environment becomes more and more intertwined through system libraries beyond the stdlib and in dependencies in general, this will become more and more common. I think it’s been mention before, but removing the requirement that protocol conformnace be as visible as the protocol would fix this nicely. I don’t recall what reasoning for the requirement was, but it seems to be more and more of a hinderance as Swift grows.
In the short term, perhaps it would be beneficial to move Range’s Codable conformance into the standard library?
Ideally this would be addressed by improving Swift but in the meantime until this happens, to quote from the other thread:
1 Like
IMO compiler should restrict extensions on stdlib types in library modules. Not everyone knows about this possibility of collision and it’ll lead to a lot of pain in the package ecosystem, some of which we’re already starting to run into.
2 Likes
Could you suggest this on the Conditional conformance collisions thread ?
It'd be better not to bifurcate discussion on what to do on the Swift side, I only created this thread to suggest reverting the change from SPM until there is a better answer in a released toolchain.
Sure