JSONSerializer uses NSNull to workaround limitation of the Cocoa collections that do not support to insert nil value.
Moreover, without a null token, it would not be possible to know if the value is present but nil or absent when trying to access it without an additional key lookup. Swift Optional provides a clean and better way to represent nil in a collection, and so don’t need NSNull at all. To my point of view, considering JSON null as something different than nil is a misconception. They both are the same thing. > Le 27 juin 2016 à 18:50, Michael Peternell via swift-evolution > <[email protected]> a écrit : > > well, JSONSerialization uses NSNull() as the null value currently. I think > this is right, because a JSON null is conceptually a different thing than > `nil as Any?` - Representing null as "not any value" a.k.a. `nil as Any?` > would be a pun in my opinion. > > -Michael > >> Am 27.06.2016 um 08:32 schrieb Jean-Daniel Dupas via swift-evolution >> <[email protected]>: >> >> >>> Le 27 juin 2016 à 00:00, Michael Peternell via swift-evolution >>> <[email protected]> a écrit : >>> >>>> >>>> Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution >>>> <[email protected]>: >>>> >>>> Optional are definitely the best way to represent null when parsing JSON. >>>> >>>>> Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution >>>>> <[email protected]> a écrit : >>>>> >>>>> Just one question: If I have functions >>>>> >>>>> json_encode(j: JSON) -> String >>>>> and >>>>> json_decode(j: String) -> JSON throws >>>> >>>> If the string is valid JSON, it return .some() optional, if ti is empty, >>>> it returns .none() optional, and if it is invalid, it throws. >>> >>> again, `.none()` is not fully specified. So your answer isn't really an >>> answer to my question. There is >> >> Optional<Any> (aka Any?) is a fully defined type. >> >>> let null1: String? = nil >>> let null2: Int? = nil >>> let null3: Any? = nil >>> >>> and null1, null2 and null3 are three different concrete values. You are >>> making it too easy for yourself when you just say `.none()`, without >>> specifying the type you are referring to. >>> >>> Also, `let x = nil` does not even compile, for exactly this reason. So >>> again, how do you want to represent a JSON null in Swift? >>> >>> let json_null: ... = ... // ??? >>> let myJSONdict = ["a":2, "b":json_null] >> >> As I said, myJSONdict can perfectly be represented as a [String:Any?] >> dictionary. >> >>> -Michael >>> >>>> >>>>> what should be the type of JSON? What should '{"a":2,"b":null}' decode to? >>>> >>>> Dictionary<String, Any?> >>>> >>>>> What should the type of the JSON null value be in Swift? >>>> >>>> Optional<Any>.none() >>>> >>>>> I think String and String? and String??? are wrong in this case. >>>>> >>>>> I'm not saying that I'm convinced that NSNull() is the best way to >>>>> represent null in this case. I just want to explain the use case that I >>>>> was thinking of. >>>> >>>> I hardly can think of a better use case than parsing JSON to demonstrate >>>> than Optional are a far better solution to represent a null value than >>>> NSNull. >>>> >>>>> -Michael >>>>> >>>>>> Am 26.06.2016 um 19:53 schrieb David Rönnqvist via swift-evolution >>>>>> <[email protected]>: >>>>>> >>>>>> I'm not convinced that Swift needs more than on way of representing the >>>>>> lack of a value. As far as I've understood (and remember), NSNull main >>>>>> reason to exist is that it's an actual object and won't for example >>>>>> terminate array literals. From what I've observed of people who are new >>>>>> to Objective-C, NSNull is a big surprise, both its general existence but >>>>>> also when to expect it (read check for NSNull to make sure one doesn't >>>>>> crash) and when not to. >>>>>> >>>>>> The way I've imagined that the same problem would be solved in Swift is >>>>>> with an optional, optional value. That is: if a field in a response can >>>>>> either be set or not, that's an optional. If that field can either >>>>>> contain a value or the explicit lack of a value that's another optional: >>>>>> >>>>>> let nickname: String?? = "Little Bobby Tables" >>>>>> >>>>>> As I see it, this is both safer (requiring that the inner nil value is >>>>>> dealt with), serves as a documentation of when an explicit missing value >>>>>> is expected and when it's not, and is more consistent. >>>>>> >>>>>> I would still expect a newcomer to wonder why there is two question >>>>>> marks in some places, but I'd imagine that that explanation would feel >>>>>> more logical. >>>>>> >>>>>> And it's (still) possible (at least in the latest Swift Playground) to >>>>>> safely unwrap both levels: >>>>>> >>>>>> if case let name?? = nickname { } >>>>>> >>>>>> - David >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> On 24 Jun 2016, at 11:32, Brent Royal-Gordon via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>>>> Not really. What is the type of Optional.none? `let empty = >>>>>>>> Optional.none` does not compile, it says "Generic parameter 'Wrapped' >>>>>>>> could not be inferred". NSNull() is a unique concrete value, and it's >>>>>>>> compatible with Objective C, NSObject and AnyObject. We could of >>>>>>>> course use `Optional<Int16>.none`, but someone else may use >>>>>>>> `Optional<AnyObject>.none` instead. The extra type information is just >>>>>>>> misleading in this case. >>>>>>> >>>>>>> If you want a single, unique value, use `()`. >>>>>>> >>>>>>> But I'm not sure why you wouldn't just make this member an >>>>>>> Optional<Any> in the first place. Is there some reason that wouldn't be >>>>>>> suitable? >>>>>>> >>>>>>> -- >>>>>>> Brent Royal-Gordon >>>>>>> Architechies >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
