1

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.

2

Sigh, I'll remove the conformance from SwiftPM. It's a bit unfortunate that we can't really create extensions on stdlib types :man_shrugging:

3

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?

4

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?

5

Ideally this would be addressed by improving Swift but in the meantime until this happens, to quote from the other thread:

1 Like
6

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
7

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.

8

Sure

9

https://github.com/apple/swift-package-manager/pull/1891

1 Like