<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 10, 2017, at 02:52, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><span class="" style="font-size: 13px;">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.</span><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">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.</div><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">It would be really great if the Foundation team could introduce a dedicated type of JSON.</div><div class="gmail_msg" style="font-size: 13px;">There are several advantages of working with a dedicated type.</div><div class="gmail_msg" style="font-size: 13px;">- The underlying data is always valid JSON</div><div class="gmail_msg" style="font-size: 13px;">- You can extend this type in the future with helper methods for manipulating JSON</div><div class="gmail_msg" style="font-size: 13px;">- It makes it explicit what you are dealing with</div><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">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.</div><div class="gmail_msg" style="font-size: 13px;"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size: 13px;">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>I haven't thought <i class="">heavily</i> 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.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>