# Conformance of Range to Codable may cause problems for libSwiftPM clients **URL:** \ **Category:** Package Manager\ **Created:** [November 18, 2018, 5:20pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104 "2018-11-18T17:20:11Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![akyrtzi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/akyrtzi/32/4963_2.png) [@akyrtzi](https://forums.swift.org/u/akyrtzi)\ **Post date:** [November 18, 2018, 5:20pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/1 "2018-11-18T17:20:11Z")
To make sure you are aware, as described in [Conditional conformance collisions](https://forums.swift.org/t/conditional-conformance-collisions/18023), `Basic`'s change to conform `Range` to `Codable` is problematic for clients that do the same thing. SourceKit-LSP already [updated its code](https://github.com/apple/sourcekit-lsp/pull/10) to avoid this problem, but you may want to do the same. ---
**Author:** ![Aciid](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/aciid/32/429_2.png) [@Aciid](https://forums.swift.org/u/Aciid)\ **Post date:** [November 18, 2018, 5:26pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/2 "2018-11-18T17:26:23Z")
Sigh, I'll remove the conformance from SwiftPM. It's a bit unfortunate that we can't really create extensions on stdlib types 🤷‍♂️ ---
**Author:** ![hartbit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hartbit/32/738_2.png) [@hartbit](https://forums.swift.org/u/hartbit)\ **Post date:** [November 18, 2018, 7:21pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/3 "2018-11-18T19:21:30Z")
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? ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [November 18, 2018, 7:54pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/4 "2018-11-18T19:54:52Z")
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? ---
**Author:** ![akyrtzi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/akyrtzi/32/4963_2.png) [@akyrtzi](https://forums.swift.org/u/akyrtzi)\ **Post date:** [November 18, 2018, 8:00pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/5 "2018-11-18T20:00:27Z")
Ideally this would be addressed by improving Swift but in the meantime until this happens, to quote from the other thread: > [@Conditional conformance collisions](https://forums.swift.org/t/conditional-conformance-collisions/18023/4): > > IMO a library that adds such a conformance is a bad citizen. A wrapper type or other alternative design should be used. It makes code clunkier, but ensures that users of the library do not run into this issue. > [@Conditional conformance collisions](https://forums.swift.org/t/conditional-conformance-collisions/18023/8): > > Extending types you do not own with protocol conformances to protocols you do not own puts you at risk of breakage. ---
**Author:** ![Aciid](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/aciid/32/429_2.png) [@Aciid](https://forums.swift.org/u/Aciid)\ **Post date:** [November 18, 2018, 8:09pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/6 "2018-11-18T20:09:08Z")
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. ---
**Author:** ![akyrtzi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/akyrtzi/32/4963_2.png) [@akyrtzi](https://forums.swift.org/u/akyrtzi)\ **Post date:** [November 18, 2018, 8:25pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/7 "2018-11-18T20:25:24Z")
Could you suggest this on the [Conditional conformance collisions](https://forums.swift.org/t/conditional-conformance-collisions/18023) 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. ---
**Author:** ![Aciid](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/aciid/32/429_2.png) [@Aciid](https://forums.swift.org/u/Aciid)\ **Post date:** [November 18, 2018, 8:26pm UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/8 "2018-11-18T20:26:14Z")
Sure ---
**Author:** ![Aciid](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/aciid/32/429_2.png) [@Aciid](https://forums.swift.org/u/Aciid)\ **Post date:** [November 30, 2018, 10:26am UTC](https://forums.swift.org/t/conformance-of-range-to-codable-may-cause-problems-for-libswiftpm-clients/18104/9 "2018-11-30T10:26:44Z")
[https://github.com/apple/swift-package-manager/pull/1891](https://github.com/apple/swift-package-manager/pull/1891)