While I can agree that this is useful in preventing things like Conformance of Range to Codable may cause problems for libSwiftPM clients, I do however have concerns about these specific types conforming to Codable. These types are somewhat special because they can be represented in many different ways, whereas types like Int, Bool, [Int], etc. all have a general form in serialization formats (e.g. "key": 123, "key": true, "key": [1, 2, 3]). We actually have a great example of this diverse representation with the issue above where SwiftPM serialized Range as, in json, {"lowerBound": 0, "upperBound": 16}, and SourceKit-LSP serializing Range as, in json, {"start": 0, "end": 16}. The proposal recognizes this and suggests wrapping Range, or similar, and customizing the serialization method used. This is both fine and not fine. Fine in a sense that we're still able to preserve our serialization method, but not fine because it is somewhat creating an issue where developers can't use the stdlib type in their code anymore (serialization wise). I just strongly suggest that we find a method that is represented very commonly.
3 Likes