> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution > <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. > If the proposal would pass in the current form, I would still use SwiftyJSON > for manipulating JSON which I would rather avoid and have this all sorted on > the Foundation level. > > Just my two cents from the perspective of an iOS developer. JSON handling is > really important to us so I hope you make it great! > > ------------------------------------------------ > Hello Swift community, > > The review of SE-0167 "Swift Encoders" begins now and runs through April 12, > 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md> > Note that this proposal is closely related to (and dependent on) SE-0166: > Swift Archival & Serialization > <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md>>. > Please read and review that proposal as well! > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at > > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > <https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>> > or, if you would like to keep your feedback private, directly to the review > manager. When replying, please try to keep the proposal link at the top of > the message: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md> > Reply text > Other replies > > <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1 > > <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>>What > goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > What is your evaluation of the proposal? > Is the problem being addressed significant enough to warrant a change to > Swift? > Does this proposal fit well with the feel and direction of Swift? > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > <https://github.com/apple/swift-evolution/blob/master/process.md> > <https://github.com/apple/swift-evolution/blob/master/process.md > <https://github.com/apple/swift-evolution/blob/master/process.md>> > Thank you, > > -Doug > _______________________________________________ > 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
