> On Apr 10, 2017, at 3:47 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Apr 10, 2017, at 02:52, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> This is a really great proposal. As an iOS developer I work with JSON >>> almost every day since most mobile apps communicate with a backend through >>> JSON messages. It's good to see that better JSON support is coming to >>> Foundation so we don't have to rely on third party libraries. >>> >>> That being said, there is one thing I don't like which is that the JSON >>> encoding function returns Data and the decoding function takes Data. >>> >>> It would be really great if the Foundation team could introduce a dedicated >>> type of JSON. >>> There are several advantages of working with a dedicated type. >>> - The underlying data is always valid JSON >>> - You can extend this type in the future with helper methods for >>> manipulating JSON >>> - It makes it explicit what you are dealing with >>> >>> A good analogy is the URL type. You could represent an URL with a String or >>> Data type, but by introducing a dedicated type you have the full advantages >>> mentioned above. Data on the other hand is like a generic container which >>> you cannot easily extend with URL or JSON specific methods. >>> >>> Having a dedicated JSON type is also one of the reasons third party >>> libraries like SwiftyJSON are so popular. It makes it super easy to >>> manipulate JSON structures. And sometimes developers like would like to >>> manipulate JSON directly. >> >> I don’t think it would be a good thing to have this in Foundation. >> Foundation needs to push developers towards adopting best practices, and >> manipulating JSON directly instead of going through Codable’s strong-typing >> is not necessarily recommended. I’m not saying it doesn’t have its uses. But >> it’s usefulness is definitely narrow now once we have Codable. I think this >> is something that should stay in a third-party library. > > I haven't thought heavily about this, but the thoughts that I have say that > JSON just isn't a good type in Swift. It's not an efficient in-memory > representation and it's not a convenient structural representation (because > of the use of either 'Any' or 'JSON' in the recursive position). I'll admit > that sometimes you're handed some JSON and you want to extract a little bit > of information out of it without building a typed representation of the whole > thing, but that still seems like something that doesn't need to be the common > path.
I agree. It seems orthogonal to this proposal to me. It would be easy enough for a library to add a Codable JSON type on top of this proposal. Foundation could even do that in the future if there was strong enough motivation for it. > > Jordan > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
